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ABSTRACT 

This  thesis  is  designed  to  propose  the  need  for  database  establishment  at  the 
Army  division  level  to  improve  the  efficiency  and  effectiveness  of  the  defense  resource 
management  system  (DRMS).  Since  the  DRMS  requires  complex  and  multi-faceted 
activities  which  includes  financial,  material,  and  facility  data,  the  application  of 
accurate  and  timely  data  is  a  crucial  component.  A  limitation  of  the  current  resource 
management  system  is  that  it  does  not  effectively  satisfy  the  user's  information 
requirements.  A  relational  database  system  can  facilitate  to  solve  these  problems  by 
the  report  generator  capability  or  ad  hoc  queries  in  a  simple  SQL  query  operation. 
Considering  the  current  situation  of  the  ROK  Army  division  equipped  with  the 
computer  mainframe,  the  initiation  of  this  study  can  provide  the  ROK  Army 
authorities  or  the  computer  experts  with  a  motivation  to  develop  the  database  system 
as  the  primary  means  of  reinforcing  the  DRMS. 
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I.  INTRODUCTION 

Korean  military  spending  is  reaching  one  third  of  the  total  government  budget 
and  6%  of  GNP.  In  spite  of  this  high  proportion,  the  goal  of  self  defense  has  not  been 
accomplished.  As  a  means  of  obtaining  defense  capability  to  balance  military  power 
between  ROK  and  North  Korea,  greater  efficiency  and  effectiveness  in  the  use  of 
defense  expenditures  is  required. 

It  was  not  so  long  ago  that  the  Korean  Army  paid  attention  to  resource 
management.  Even  though  we  have  run  through  a  series  of  trial  and  error  in  the 
resource  management  system,  we  could  not  establish  a  well-developed  system  for 
controlling  operational  data  and  for  measuring  performance  in  terms  of  cost 
effectiveness  analysis.  Furthermore,  the  absence  of  reliable  data  about  operating 
activities  made  it  difficult  to  analyze  and  evaluate  possible  improvements. 

A.      THESIS  OBJECTIVE 

This  thesis  examines  the  current  ROKA  defense  resource  management  system 
(DRMS)  and  proposes  an  DRiMS  database  design  at  the  division  level  to  improve  its 
efficiency  and  effectiveness. 

Since  the  resource  management  system  deals  with  very  complex  and  multifaceted 
financial,  material,  and  facility  activities,  the  availability  of  accurate  and  timely  data  is 
a  crucial  factor  in  the  successful  allocation  and  expenditure  of  limited  resources. 

This  thesis  is  developed  around  the  following  questions: 

1.  What  is  the  current  resource  management  system  of  ROKA? 

2.  What  are  the  information  requirements  for  the  effective  resource  management? 

3.  How  can   a   relational   database   management   system  support   the   resource 
management  in  the  division  level? 

4.  How    can    data    manipulation    of   the    relational    model    meet    the    diverse 
information  requirements? 

5.  What  capabilities  exist  for  expenditure  analysis  and  performance  evaluation  in 
this  database  environment? 

The  overall  objective  of  the  thesis  is  to  propose  a  course  of  action  to  improve 

ROKA  resource  management  system  from  the  user's  point  of  view,  and  to  show  the 

possible  application  of  the  relational  model  database  in  the  data  analysis. 
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B.  THESIS  ORGANIZATION 

The  thesis  consists  of  6  main  chapters.  Chapter  II  provides  the  overview  of  the 
current  ROKA  resource  management  system.  Limitations  as  well  as  the  status  quo  will 
be  surveyed  as  the  starting  point  of  this  thesis. 

Clear  identification  of  the  information  requirement  is  the  fundamental  matter  for 
any  database  approach.  In  Chapter  III,  the  user's  needs  are  examined.  The 
identification  of  required  output  data  will  provide  the  motivation  for  the  database 
design. 

Chapter  IV  introduces  the  principal  concepts  of  the  data  management  approach 
from  the  user's  viewpoint.  The  main  topics  are:  what  is  the  database?;  why  do  we  need 
a  database?;  how  is  it  operated? 

The  main  research  of  the  thesis  will  be  performed  in  Chapters  V  and  VI.  In 
Chapter  V,  the  actual  transaction  or  activities  of  the  resource  management  system  are 
represented  as  tables  to  be  manipulated  in  a  relational  database  management  system. 
(The  relational  model  is  widely  accepted  as  a  powerful  and  flexible  database  technique.) 
Examples  are  provided  to  show  how  to  derive  the  required  information  by  using  the 
SQL  data  manipulation  language.  Chapter  VI  describes  various  analyses  of  the 
resource  management  expenditures  which  can  be  derived  from  this  database.  We  will 
demonstrate  the  analysis  with  appropriate  models  in  three  cases. 

Finally,  based  on  the  preceding  research,  we  conclude  the  theses  by  proposing  a 
course  of  actions  to  implement  an  effective  and  efficient  resource  management  system 
in  ROKA  division  level. 

C.  THESIS  SCOPE 

Throughout  the  thesis,  the  detailed  technical  issues  on  information  systems  and 
database  design  will  not  be  covered,  rather  we  focus  on  the  application  capability  of 
the  output  data  in  the  relational  model.  Since  the  urgent  requirement  for  the  ROKA 
in  coping  with  the  resource  management  is  the  availablity  of  the  timely  and  accurate 
operational  data,  our  main  concern  is  a  well-developed  database  system  as  the  key 
element  of  the  resource  management  information  system. 
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II.  REVIEWS  OF  REPUBLIC  OF  KOREA  (ROK)  DEFENSE  RESOURCE 

MANAGEMENT  SYSTEM 


A.  GENERAL 

In  order  to  provide  funding  for  an  increase  in  capital  investment,  in  July  1983, 
Republic  of  Korea  (ROK)  President  Chun  issued  an  executive  order  requiring  the 
Korean  armed  forces  to  reduce  the  operating  expenditure  in  the  nation's  defense 
budget  [Ref.  1:  p.  3].  The  objective  of  this  order  was  to  take  initial  steps  toward 
improving  defense  resource  management. 

While  the  ROK  economy  has  made  excellent  progress,  defense  spending  is 
reaching  6%  of  GNP  or  approximately  one  third  of  the  government  budget.  This 
figure  is  considered  high  by  free-world  standards.  Despite  this  high  level  of  spending, 
the  imbalance  of  military  power  between  the  two  Koreas  remains  in  favor  of  the  North 
as  shown  Table  1  [Ref.  2:  pp.  59-63]. 

As  a  means  of  obtaining  greater  defense  capabilities  to  balance  military  power 
between  South  and  North,  the  Government  of  ROK  has  taken  steps  to  obtain  greater 
efficiency  in  its  use  of  defense  funding.  Promoting  the  efficiency  of  defense  operating 
expenditures  will  be  the  best  way  to  accomplish  the  objective  of  self-defense. 

B.  REVIEW     OF     THE     REPUBLIC     OF     KOREA     DEFENSE     RESOURCE 
MANAGEMENT  SYSTEM 

1.  Background  and  History 

U.S.  security  assistance  to  the  ROK  has  played  an  essential  role  in 
strengthening  the  military  capabilities  of  the  ROK.  In  the  past,  Korea's  main  focus  of 
defense  management  was  to  obtain  as  many  resources  as  possible.  Government  policy 
makers  didn't  feel  the  need  for  advanced  management  systems  and  specialists  to 
enhance  defense  productivity. 

In  the  1950s  and  1960s,  arms  transfers  from  the  U.S.  were  made  under  the 
Military  Assistance  Program  (MAP);  during  the  subsequent  period  of  ROK  Armed 
Forces  Modernization  Program  (1971-1975),  the  military  capabilities  of  ROK  were 
greatly  enhanced  under  such  U.S.  Military  Aids  Programs  as  MAP  and  the  Military 
Assistance  Service  Fund  (MASF). 

Since  the  mid-1970s,  U.S.  security  assistance  policy  toward  ROK  has 
undergone  a  tremendous  change.    Assumption  of  increased  responsibility  for  its  own 
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TABLE  1 

COMPARISON  OF  MILITARY  POWER  BETWEEN  SOUTH  AND 

NORTH 

Contents 

ROK 

North  Korea 

Rate 

*  Man  power 

-  Regular 

-  Reserve   Forces 

622,000 
5,780,000 

785,000 
5,170,000 

1    :     1.3 
1.2    :     1 

*   Equipment 

-  Artillery 

-  Tank 

-  Armored  Vehicle 

-  Submarine 

-  Destroyer 

-  Naval   Vessels 

-  Bomber/Fighter 

-  Transporter 

-  Total  Aircraft 

2,800 

1,200 

800 

20 
101 
450 

61 
618 

5,300 

3,200 

1,200 

21 

2 

537 

-       740 

369 

1,322 

1    :     1.9 
1    :     2.  7 
1    :     1.5 

1    :     5.3 

1    :     2.1 

*   Defense    spendings 

-  GNP( 1983) 

-  Defense   Budget 

-  Cumulative   total 
Since    1970 

$    75.3    B 
$      4.  34B 

$    28.53B 

$    14.  5   B 
$      3.4   B 

$    31.4  B 

5.2  :     1 

1.3  :     1 

1    :     1.  1 

defense  made  ROK  MOD  realize  the  need  for  a  better  and  more  efficient  allocation  of 
defense  resources.  Toward  this  end,  the  U.S.'s  Planning,  Programming,  and  Budgeting 
System  (PPBS)  was  studied  and  introduced.  Finally,  the  Planning,  Programming, 
Budgeting,  Execution,  and  Evaluation  System  (PPBEES)  unique  to  ROK  military 
needs  was  developed  as  shown  in  Figure  2.1  [Ref.  3:  p.  86]. 

The  concept  of  PPBEES  is  to  design  a  bridge  between  the  planning  and 
programming  phases  and  to  feed  back  the  results  of  performance  evaluations  for  use  in 
subsequent  phases  of  planning,  programming,  and  budgeting.  Under  PPBEES, 
increments  to  programs  were  considered  in  the  programming  phase  and  these 
increments  were  then  translated  into  line  item  entries  for  the  traditional  budget 
submission.  [Ref.  4:  p.  91]  This  PPBEES  system  aims  to  develop  a  sound  Defense 
Resource  Management  System  by  adding  the  execution  and  evaluation  phases  to  the 
previous  budget  system. 
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Programming 


Budgeting 


Strategic 
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Five  Year 
Plan 


Plan 


Annual 
Budget 


<===== 
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Evaluation 


Execution 
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Detailed 
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See 
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Do 

<== 

== 
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Execution  Result  Report 


Note 


MBO  :  Management  by  Objectives 
MBE  :  Management  by  Exception 
MBF  :  Management  by  Feedback 


Figure  2.1     The  PPBEES  System. 

On  February  25,  1983,  the  Defense  Budget  Revolution  Committee  was 
established  in  order  to  make  an  intrinsic  improvement  in  the  defense  budget  system. 
Its  main  objective  was  to  establish  a  rational  cyclic  process  of  planning,  programming, 
budgeting,  execution,  evaluation.  [Ref.  4:  p.  7]  The  Budget  Revolution  Committee 
selected  eight  major  functions  to  implement  the  PPBEES  system.   [Ref.  1:  pp.  17-32] 

The  eight  major  functions  are: 
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Decision-making  process 
Planning-programming  process 
Program  management  system 
Decentralized  management  system 
Analysis  and  evaluation  system 
Management  information  system 
Resource  management  staff  function 
Reorganization 
These  are  explained  in  detail  in  the  following  section. 

2.  Decision  Making  Process 

a.  Basic  Concept 

The  process  suggests  that  the  national  defense  objectives  be  translated  into 
budgetary  decisions.  After  identifying  alternatives  necessary  to  carry  out  the  mission, 
cost-effectiveness  analysis  for  defense  related  programs  are  to  be  performed  in  order  to 
determine  the  priority   of  alternatives  within  the  given  budget  constraints. 

b.  Directions  toward  Reform 

At  the  beginning  stage,  each  project  requires  an  analysis  report  to  justify  its 
budget  request  in  detail;  thus  nonessential  projects  can  be  eliminated  early.  For  the 
appropriate  force-mix,  first,  we  establish  the  strategy  concept  to  meet  the  enemy's 
threat  and  then  decide  the  resource  allocation  between  each  force  (Army,  Navy,  Air 
Force,  Homeland  Reserve  Forces). 

In  the  past,  the  Korean  government  had  focused  on  the  process  of 
obtaining  a  budget,  therefore,  the  execution  and  evaluation  phases  were  not  considered 
in  detail.  There  was  no  consistency  in  the  management  cycle  of  planning- 
programming- budgeting.  Because  of  the  abstract  nature  of  programming  criteria, 
planning  was  not  sound.  Distribution  of  defense  resources,  therefore,  was  inefficient, 
and  the  productivity  of  the  defense  budget  was  very  low.  [Ref.  1:  p.  17] 

3.  Planning-Programming  Process 
a.   Basic  Concept 

The  concept  of  planning-programming  process  explains  the  process  of 
budget  organization.  It  is  important  to  understand  the  roles  of  both  long-range  and 
short-term  planning  in  the  overall  planning  scheme.  Requests  for  military  forces  to 
meet  the  strategic  and  force  maintainance  programming  must  be  coincident. 
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b.  Directions  toward  Reform 

By  integrating  the  Strength  Improvement  Plan1  and  Defense  Five- Year 
Program,  the  investment  budget  and  operating  expenditure  could  be  allocated 
properly.  The  adjust  and  control  function  of  budget  programming  would  be 
strengthened. 

Evaluation  of  projects  can  be  performed  more  easily  by  using  uniform 
documents  in  the  planning,  programming,  and  budgeting  process  as  shown  in  Table  2. 
[Ref.  3:  pp.  90-91] 

It  is  then  possible  to  manage  defense  projects  more  effectively.    Each 
expenditure  criteria  derived  from  comparing  the  performance  result  of  user-level  units 
can  be  used  as  guidance  for  planning  and  budget  organization.   [Ref.  1:  p.  19] 
4.  Program  Management  System 
a.   Basic  Concept 

Until  now,  weapon  system  procurement  programs  were  performed  by  ROK 
iMOD  according  to  the  Strength  Improvement  Program.  However,  the  maintenance 
and  supply  support  plans  were  performed  by  each  service  department,  so,  there  were 
no  responsibility  centers  for  each  stage.  Korean  military  planners  believe  that  each 
program  must  have  consistency  from  beginning  to  end.  Therefore,  the  weapon  system 
selection  phase,  research  and  development,  test  and  evaluation,  production,  quality 
assurance,  procurement,  deployment,  and  operation  phases,  all  must  have  consistency. 
At  the  first  stage,  that  program  which  has  the  highest  priority  is  selected  based  on  its 
level  of  investment  or  contribution  to  strength  improvement  (strengthening  of  war 
potential).  Secondly,  a  project  manager  will  be  selected  to  improve  the  efficiency  of 
program  execution  and  management  of  weapon  system  organization  and  logistic 
support.  The  manager  selected  must  be  accountable  and  must  be  given  the  necessary 
authority  to  fulfill  these  responsibilities. 


lThis  plan  started  after  the  8th  session  of  the  Korea-U.S.  Ministerial  Security 
Conference  of  August  1975.  The  principal  ingredients  of  the  plan  are  the  increase  of 
military  hardware,  the  expansion  of  defense  facilities  and  the  development  of  the 
defense  industry.  At  the  begining  stage,  the  primary  fiscal  sources  were  the  national 
defense  tax  and  U.S.  fmancial  support  and  other  cooperation.  Currently,  the  main 
source  is  the  national  defense  tax. 

2Based  on  the  Strength  Improvement  Plan  this  program  is  aimed  at  securing  a 
defense  capability  to  repel  north  Korean  Aggression  unaided  by  China  or  Russia.  This 
program  called  for  the  attainment  of  this  goal  within  5  years,  starting  from  1975.  After 
the  first  5-Year  Program,  however,  every  5  years,  new  5- Year  Programs  have  been 
extended. 
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TABLE  2 
DOCUMENTS  IN  PLANNING-PROGRAMMING-BUDGETING  CYCLE 

Month 

Year  X-3 

Year  X-2 

YearX-1 

JAN 
FEB 

Long  Range  Strategy 
and  Policy 

National  Strategic 
Objective  Plan, 

Research  and 
Development  Plan 

Militarv  Budget 
Requirements 

MAR 

Middle  Range 
Intelligence 
Estimation 

Middle  Range 
Defense  Policy 

- 

APR   - 

- 

5  Year  Plan 

Guidance, 
Strength  Improvement 

Guidance 

- 

MAY 

Strategic  objective 

Guiaance, 
Research  and 

Development 

Guidance 

- 

Defense  Budget 

Requirement, 
Service  Improvement 

Executive  Guidance 

J  UN 
JULY 

- 

Service  Strength 
Improvement 
Requirement 

Service  Strength 
Improvement  Plan 

AUG 

- 

Service  5  Year 
Requirement 

- 

SEPT 

Service  Strategic 
Objective  Plan, 

Service  Research  and 
Development  Plan 

- 

- 

OCT 

- 

Strength 
Improvement  Plan 

Defense  Strength 
Improvement 
Execution  plan 

NOV 

- 

Annual  Defense 
Policy 

- 

DEC 

- 

- 

National  Assembly 
Authorization  and 
Appropriation 
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b.  Directions  toward  Reform 

Project  management  requires  approval  of  high  authority  at  key  decision 
points  (milestones).  Life  cycle  cost  (LCC)  is  considered  on  an  equal  basis  with  system 
performance,  schedule,  and  logistic  supportability.  A  clear  line  of  authority, 
responsibility,  and  accountability  for  the  management  of  programs  is  established. 
Competition  in  contracting  is  also  required.  [Ref.  5:  pp.  36-38] 

5.  Decentralized  Management  System 

a.  Basic  Concept 

The  unit  commander  has  the  responsibility  for  managing  the  unit's 
resources  such  as  manpower,  funds,  materials,  and  facilities.  Complete  autonomy  in 
spending  on  the  part  of  the  operational  commander  is  emphasised.  First,  the 
commander  will  be  motivated  to  control  costs  by  establishing  his  ownership  and 
responsibility  to  manage  his  unit  efficiently.  Secondly,  each  soldier  will  be  motivated 
to  find  cheaper  substitutes,  because  the  remaining  funds  which  result  from  efficient 
management  could  be  used  for  the  soldiers'  welfare,  such  as  recreation  facilities,  a 
library,  sport  equipment,  etc. 

By  developing  a  proper  accounting  report  system,  it  is  possible  to  estimate 
the  performance  of  each  unit  and  summarize  aggregate  totals.  For  example,  1/4  ton 
jeep  operation  can  be  divided  into  3  categories  according  to  the  following  purposes  : 
commanding,  operation,  and  administration.  The  maintenance  cost  per  vehicle  could  be 
compared  with  that  of  the  same  purpose  vehicle  of  other  troops,  but  it  is  difficult  to 
say  that  lower  cost  always  means  better  performance. 

b.  Directions  toward  Reform 

By  strengthening  the  function  of  resource  management,  each  unit 
commander  can  assess  his  unit's  assets  and  make  an  analysis  of  the  results  of  his 
resource  spending,  which  can  facilitate  economic  troop  management.  To  establish  the 
management  information  system,  it  is  necessary  to  first  develop  a  new  accounting 
system  that  can  integrate  the  total  resources  and  adopt  the  user-centered  logistic 
management  which  is  based  on  decentralized  principles.   [Ref.  5:  pp.  34-36] 

6.  Analysis  and  Evaluation  System 
a.   Basic  Concept 

This  system  was  established  to  provide  basic  data  needed  in  successive 
planning,  programming,  and  budget  compilations.  The  basic  data  can  be  derived  from 
the  result  of  comparative  analysis  between  the  required  mission  performance  level  and 
the  results   of  resource  spending. 
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b.  Directions  toward  Reform 

The  mission  performance  level  and  the  result  of  resource  spending  could  be 
analyzed  and  evaluated  by  developing  a  new  accounting  system  and  the  establishment 
of  a  new  auditing  policy  which  is  consistent  with  the  concept  of  resource  management. 
At  the  programming  and  budgeting  stage,  the  previous  data  of  expenditure  analysis 
could  be  used  to  make  programming  decisions  as  well  as  budget  formation  based  on 
performance  criteria. 

7.  Management  Information  System  (Computer-Based) 

a.  Basic  Concept 

In  order  to  operate  the  Defense  Resource  Management  System  efficiently, 
information  (demand,  procurement,  operating-inventory  control,  performance 
evaluation...)  must  be  provided  at  the  right  time  and  right  place.  This  system  must  be 
computerized  to  obtain  the  benefits  of  speed  and  accuracy.  This  system  also  can  assist 
in  decision  making  for  resource  allocation. 

b.  Directions  toward  Reform 

DBMS  (Data  Base  Management  System)  was  established  to  assist  the 
process  of  analysis,  evaluation  and  the  accurate  computation  of  resource  demands. 
Constructing  computer  networks  among  MOD,  each  division  of  the  Army,  Naval 
theatre  commands,  and  Air  Force  flying  corps  will  facilitate  this  process.  [Ref.  6:  p.  13] 

Computerized  inventory  management  of  logistic  materials  and  other  major 
resources  can  facilitate  the  decentralization  of  the  resource  management  system,  which 
includes  procurement,  storage,  and  distribution  procedures.  Computerizing  the 
process  of  5  year  programming,  budget  organization,  and  execution,  can  accomplish 
the  objective  of  budget  revolution  in  a  short  time. 

8.  Resource  Management  Staff  Function 

a.  Basic  Concept 

Strengthening  the  function  of  the  resource  management  staff  is  intended  to 
support  the  decentralized  unit  management  system  by  properly  giving  incentives  to  the 
units  according  to  their  performance. 

b.  Directions  toward  Reform 

Three  separate  functions  (finance,  logistics,  and  facility  engineering)  were 
integrated  and  the  overall  management  staff  controls  all  resources.  The  overall 
management  staff  is  responsible  for  all  resource  management  in  the  unit,  and  so  seeks 
the  most  economic  level  of  unit  operation,  prepares  the  unit's  budget,  and  handles 
material  accounting  and  fund  accounting.   [Ref.  1:  p.  31] 
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9.  Reorganization 

a.  Basic  Concept 

The  newly  designed  Defense  Resource  Management  System  is  based  on  the 
concept  of  PPBEES  (planning,  programming,  budgeting,  execution,  evaluation  system). 
Thus,  a  new  organizational  structure  is  needed  to  support  the  new  procedure.  This  will 
require  integration,  restructuring  and  reinforcement  of  the  new  system  to  reorganize 
the  current  structure  to  meet  the  new  task. 

b.  Directions  toward  Reform 

The  old  structure  must  be  reconized  through  changes  based  on  an 
integrated  logistic  system.  A  part  of  the  new  organization  must  be  a  cost  and  program 
analysis  function  which  should  be  accomplished  through  a  special  organization  manned 
by  professional  personnel.   [Ref.  1:  p.  32] 

After  introducing  the  Defense  Resource  Management  System  in  1983,  ROK 

MOD  has  made  a  concreted  effort  to  implement  the  system  in  the  ROK  military  as 

follows: 

Selection  of  the  sample  units  according  to  the  type  of  troops. 

Design  of  the  common  structure  documents  used  in  the  programming  and 
budgeting  phases. 

Implementation  of  the  system  in  the  experimental  troops. 

Evaluation  of  the  performance  results  in  the  experimental  troops. 

Amendment  and  reinforcement  in  the  intrinsic  nature  of  Defense  Resource 
Management  System  introduced. 

•      Inspection  of  the  execution  of  the  system. 

Finally,  from  the  beginning  of  1986,  the  Defense  Resource  Management  System 
is  being  implemented  throughout  the  MOD.  The  Defense  Management  Accounting 
System  is  designed  to  assist  the  newly  proposed  Defense  Resource  Management 
System.  The  objective  of  this  system  (procedure)  is  to  provide  standardized  data  for 
resource  management  to  each  level  commander.  [Refs.  7,8]  Accounting  information 
has  two  major  purposes  :  decision  making  and  performance  evaluation.  For  example, 
managers  can  easily  decide  the  proper  disposal  time  of  an  equipment  by  using  the 
accounting  information.  Regression  analysis  is  one  of  the  common  techniques  to 
produce  the  accounting  information. 

The  Defense  Management  Accounting  System  is  intended  to  support  not  only 
the  decentralized  unit  resource  management  system,  which  is  one  of  the  eight  major 
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functions  of  the  budget  revolution  movement,  but  also  the  PPBEES  which  is  the  main 
objective  of  the  defense  management  system. 

Until  1984,  legal  accounting  procedures  had  been  used  to  provide  the  legal  result 
of  resource  expenditures.  The  private  sector's  accounting  theory  was  adjusted  to  meet 
the  characteristics  of  military  needs.  The  analysis  of  performance  and  resource 
spending  results  can  now  be  obtained  through  cost  analysis. 

To  accomplish  this  new  accounting  procedure,  the  Budget  Revolution  Committee 
adopted  the  unified  accounting  system  based  on  the  double  entry  bookkeeping 
principle.  Everything  that  has  any  economic  value  must  be  recorded  and  analyzed 
according  to  the  proposed  accounting  system.  For  example,  suppose  that  there  is  a 
useful  plant  on  the  base;  the  monetary  value  of  the  plant  must  also  be  evaluated 
according  to  its  growth,  so  annually,  or  at  every  prescribed  term  period,  its  value  must 
be  reevaluated. 

Two  different  kinds  of  accounting  methods  are  used,  according  to  the  type  of 
unit.  The  corporate  accounting  system  (also  called  special  accounting)  is  adapted  to 
production,  maintenance  units  and  education  units.  On  the  other  hand,  general 
combat  units  use  a  different  accounting  system  from  the  corporate  accounting  system. 
This  is  called  the  general  accounting  system  and  is  similar  to  U.S.  Government 
accounting  procedures. 

The  general  accounting  system  does  not  permit  the  concept  of  depreciation, 
which  is  regarded  as  an  expenditure  at  the  time  of  disposal.  Prepayments  are  also 
regarded  as  expenditures  not  as  assets,  which  make  up  the  capital.  In  the  general 
accounting  system,  bonus  payments  are  recognized  at  the  point  of  occurrence,  but  in 
the  special  accounting  system,  the  average  of  payments  is  recorded  as  expenditures  in 
each  period.  Classification  of  expenditure  as  direct  and  indirect  is  needed  in  the  special 
accounting  system  but  not  in  the  general  accounting  system. 

C.       CURRENT  RESOURCE  MANAGEMENT  SYSTEM 

Resource  management  system  (RMS)  are  a  series  of  systems  designed  to  promote 
better  management  through  the  ROK  MOD  by  providing  managers  with  improved 
means  of  obtaining  and  controlling  the  resources  required  to  accomplish  missions. 
They  also  include  procedures  which  are  closely  related  to  quantitative  systems  even 
though  the  system  may  not  themselves  be  primarily  quantitative.  Resources  are  men, 
materials,  services,  and  money. 


22 


A  resource  manager  is  any  individual  who  is  responsible  for  carrying  out  a 
significant  mission  or  function  and  who  in  so  doing  makes  decisions  that  have  a 
significant  effect  on  the  resources  used.  For  the  military  commander  this  means  that 
responsibility  for  management  is  added  to  the  traditional  responsiblity  for  command. 

1.  Objectives  of  RMS 

The  objectives  of  RMS  are: 

•  to  provide  managers  at  all  levels  within  the  ROK  MOD  with  information  that 
will  assist  them  in  assuring  that  resources  are  obtained  and  used  effectively  and 
efficiently  in  the  accomplishment  of  MOD  objectives. 

•  to  provide  information  that  useful  in  the  formulation  of  objectives  and  plans. 

•  to  provide  data  to  support  program  proposals  and  requests  for  funds. 

•  to  provide  a  means  of  assuring  that  statutes  and  other  requirements  relating  to 
resources  are  complied  with.   [Ref.  8:  p.  11] 

2.  Structure  of  RMS 

The  structure  of  RMS  is  designed  to  establish  the  criteria  of  each  management 
accounting  unit  and  lead  each  unit  to  have  responsibilities  for  its  resources  and 
consumption  of  the  resources.  Through  the  structure  of  RMS  it  can  be  possible  to 
measure  the  resource  requirements  that  each  management  accounting  unit  needs,  to 
motivate  a  resource  manager  by  comparing  with  the  performance  of  other  unit,  and  to 
vest  the  authorities  and  responsibilities  of  resource  management  in  resource  managers. 

The  structure  of  RMS  consists  of  five  levels,  such  as  command  and  control 
unit,  mid-management  unit,  resource  management  unit,  expense  collecting  unit  and 
consuming  unit  as  shown  in  figure  2.2.  [Ref.  8:  p.  20]  Higher  level  unit  controls  lower 
level  unit  and  lower  level  unit  report  to  the  higher  level. 

a.  Command  and  Control  Unit 

Command  and  control  unit  is  the  top  management  level  which  collects, 
analyzes,  and  evaluates  all  kinds  of  reports,  determines  the  standard  expenses,  and  is 
concerned  with  establishing  policies  and  developing  plans.  Ministry  of  Defense  (MOD) 
and  ROKA  Headquarters  are  the  command  and  control  units. 

b.  Mid-level  management  unit 

Mid-level  management  unit  is  the  second  highest  management  level  that 
collects  various  reports  from  subordinate  units,puts  the  reports  together,  and  reports 
them  to  the  command  and  control  unit.  Headquarters  of  Field  Army  and  Corps  are 
mid-level  management  units.  Mid-level  management  unit  becomes  a  management 
accounting  unit  and  has  a  responsibility  for  the  resource  management  and  reporting  to 
the  higher  level. 
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Figure  2.2     Structure  of  RMS. 

c.  Resource  Management  Unit 

Resource  management  units  are  the  principal  and  elemental  units  of 
resource  management  which  are  concerned  with  estimating  budget  requirements,  using 
and  controlling  resources,  and  producing  various  managerial  data  and  reports.  It  has  a 
responsibility  for  reporting  to  the  higher  level.  Typically,  Army  divisions  become 
resource  management  units. 
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</.  Expense  Collecting  Unit 

Expense  collecting  units  are  the  subordinate  unit  of  resource  management 
units,  such  as  Infantry  Regiments,  which  record  various  operating  expenses,  prepare 
periodic  reports,  and  report  to  the  resource  management  unit  according  to  directions 
and  coordinations  of  the  upper  level  unit. 
e.   Consuming  Unit 

Consuming  units  are  the  lowest  subordinate  units  of  expense  collecting 
units,these  are  usually  companies.  The  consuming  unit  records  all  kinds  of  expenses 
whenever  consuming  events  occur  and  report  to  the  expense  collecting  unit  through  the 
simplest  channels,  such  as  telephone,  oral  message,  messengers. 
/.    Unit  Identification  Code 

Unit  identification  code  is  designed  to  computerize  the  processes  that 
continuously  accumulate  all  the  expenses  resulting  from  using  the  resources  of  a  unit. 
In  the  resource  management  system  for  operations  the  unit  identification  code  is  the 
basic  classification  device  whereby  expense  information  is  related  to  a  program.  ROK 
iMOD  makes  the  unit  classification  code  and  manage  it  and  the  unit  classification  code 
is  created  in  a  manner  as  shown  in  Figure  2.3.   [Ref.  8:  p.  21] 
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Figure  2.3     Unit  Classification  Code. 

3.  Accounting  Records  and  Files 

Accounting  records  required  under  RMS  are  made  up  of  ledgers,  journals, 
basic  cost  records,  and  control  records.  The  number  and  kinds  of  journals,  ledgers,  and 
other    documentation    records    required    depend    upon    the    type    and    volume    of 
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transactions,  the  desires  of  the  major  claimant,  and  the  nature  and  level  of  the  unit 
mission  and  organization. 

The  general  ledger  is  the  book  of  accounts  in  which  all  accounting  entries  are 
ultimately  summarized.  A  general  ledger  is  maintained  for  each  unit  activity.  The 
account  structure  in  the  general  ledger  is  specifically  designed  to  accumulate  financial 
data  necessary  to  render  meaningful  reports  to  management.  The  chart  of  accounts 
carried  in  the  general  ledger  is  shown  in  Figure  2.4.  [Ref.  8:  pp.  25  -  69]  Not  all 
accounts  listed  will  be  found  in  all  general  ledger;  Only  those  used  by  the  unit  activity 
holding  the  operating  budget  are  found  in  the  general  ledger  at  that  unit  activity. 


Major  Classification 

Asset  accounts 
Liability  accounts 
Capital  accounts 
Budgetary  accounts 
Contra  accounts 
Expense  accounts 


Account  series 

1000  -  1999 
2000  -  2999 
3000  -  3999 
4000  -  4999 
5000  -  5999 
6000  -  7000 


Figure  2.4    Chart  of  Accounts. 

4.  General  Procedure  of  Resource  management  Accounting 

Resource  management  accounting  procedure  is  a  series  of  processes  that 
consists  of  identifying  transaction,  recording  transaction,  accounting  process,  closing 
entry,  and  preparing  reports  as  shown  in  Figure  2.5.  [Ref.  8:  p.  74] 

a.  Identifying  Transaction 

A  transaction  means  an  activity  that  is  recognized  as  accounting  events 
associated  with  resources  of  a  unit.  In  general,  events  are  recognized  as  transactions 
only  if  they  receive,  transfer,  release,  or  consume  resources. 

b.  Recording  Transaction 

A  resource  transaction  slip  (RTS)  is  recorded  whenever  transactions  occur. 
RTS  is  a  kind  of  computer  input  document  designed  to  process  various  resource 
transactions  through  a  computer  as  shown  in  Figure  2.6.   [Ref.  8:  p.  153] 
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Identifying 
Transaction 


Equipments,  Materials,  Facilities, 
Cash  and  Budget 


Recording 
Transaction 


Resource  Transaction  Sheet 


*  Consumption  of 
resources 

*  Various  transaction 


Accounting 
Process 


Producing 


Input 


Data 


General 


subsidiary 


general 
journals 


?eneral 
edgers 


materials 

general 
udget 
expenses 


facilities 

general 

equipments 


Closing 
Accounts 


Trial 


Balance 


Preparing 
Report 


*  Balance    Sheet 

*  Operating  expense 
report 

*  Others 


Figure  2.5     Resource  Management  Accounting  Procedure. 

The  results  of  consumption  of  the  expense  collecting  unit  and  various 
resource  transactions  (supply  transaction,  budget  transaction,  maintenance  transaction, 
gratuitous  transaction,  allotment  transaction,  and  others)  are  recorded  in  RTS. 
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c.  Accounting  Process 

In  this  stage,  resource  transaction  slips  are  examined  and  modified  when 
omissions,  overlaps,  or  errors  are  found.  A  transaction  file  is  produced  by  inputing  all 
the  resource  transaction  data.  A  Journal  file  is  created  from  the  transaction  file 
thereafter.  All  the  transactions  of  the  journal  file  are  recorded  in  the  general  ledger  and 
each  subsidiary  ledger. 

d.  Closing  accounts 

Closing  accounts  is  a  procedure  for  preparing  a  trial  balance,  adjusting 
entries  and  various  reports  at  the  end  of  each  quarter  or  year.  A  trial  balance  is  a 
listing  of  each  of  the  accounts  in  the  general  ledger  with  its  balance  at  a  particular 
time.  All  accounts  with  debit  and  credit  balances  are  listed  and  summed.  Closing 
accounts  occur  quarterly  and  yearly. 

e.  Preparing  Report 

Reporting  is  one  form  of  responsibility  accounting.  The  commanding 
officer  (CO)  has  at  his  disposal  a  number  of  management  and  financial  reports  under 
RMS.  Some  reports  are  used  by  the  CO;  others  are  forwarded  to  the  management 
echelon. 

Reporting  provides  information  on  the  operating  expenses  and  obligations, 
operating  budgets,  and  performance  of  field  activities. 

Reports  forwarded  upward  are  briefly  listed  in  Figure  2.7.    [Ref.  8:  p.  86] 
Reports  for  the  CO  are  very  flexible  depending  upon  characteristics  of  a  unit,  but  now 
they  are  not  established  well  in  current  RMS. 
5.  Current  computer  flowchart  of  RMS 

A  computer-based  system  was  regarded  as  the  key  tool  in  the  successful 
implementation  of  RMS,  and  each  resource  management  unit  (Army  division  level)  was 
linked  to  the  computer  mainframe.  However,  the  computer  system  for  RMS  was 
installed  without  sufficient  preparation  and  experience,  and  it  is  undergoing  deficiencies 
in  its  operating  system  and  is  not  meeting  the  total  user's  needs.  Current  computer 
flowchart  of  RMS  is  shown  in  Figure  2.8.   [Ref.  9:  p.  7] 

D.      LIMITATIONS  OF  CURRENT  RMS 

The  importance  of  MIS  as  an  efficient  tool  to  carry  out  the  PPBEES  system  was 
perceived  and  the  distributed  computer  system  was  implemented  at  the  Army  division 
level  by  the  end  of  1986.  The  computer  is  now  used  to  perform  the  resource 
management  work,  but  at  the  primitive  stage. 
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NO 

REPORT  NAME 

CONTENTS 

1 

Balance  Sheet 

*  All  assets  and  resource 
transactions  of  a  unit. 

2 

Operating 

expense 

report 

*  Operating  performance  and 
expense  of  the  unit  s 
resources. 

3 

Expense 

management 

report 

*  Total  amount  of  each 
expense  elements. 

*  Comparison  of  each  unit  s 
expenses. 

*  Expense  data  of  each 
equipment. 

*  Expense  data  of  each 
facility. 

4 

Equipment 

management 

report 

*  Operating  performance 
or  each  equipment. 

*  The  present  condition  of 
each  equipment. 

5 

Facility 

management 

report 

*  The  present  position 
of  each  facility. 

6 

Material 

management 

report 

*  The  present  position  of 
each  unit  s  materials. 

*  Material  transaction 
and  its  performance. 

7 

Budget  control 
report 

*  Performance  of  use 
of  cash  and  budget. 

+   Responsible  Unit:  Resource  Management  Unit. 
+   Term  of  each  report:  Quarterly. 


Figure  2.7     Reports  forwarded  upward. 

The  ROK  Army  is  striving  to  improve  the  efficiency  and  effectiveness  of  its 
defense  resource  management.  However,  it  is  experiencing  some  problems  in  the  RMS 
which  is  caused  by  insufficient  preparation  and  inexperiences  in  its  early  stage. 
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Figure  2.3     Flowchart  of  RMS. 

1.  MIS  and  Data  Analysis  Models 

Decentralized  management  system,  one  of  the  eight  major  functions  to 
implement  the  PPBEES  system,  is  highly  recommended  for  use  in  the  ROK  Army. 
Every  unit  is  classified  into  eight  unit  categories:  combat  unit,  logistics  &  support, 
intelligence,  communication,  headquarters  &  administration,  hospital,  school/institute. 
Each  unit  has  its  own  mission  and  characteristics,  therefore  each  unit  must  have  its 
own  budgeting,  controlling,  and  evaluating  system.  To  get  the  useful  information  for 
decision  making,  each  unit  must  have  its  own  MIS. 
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However,  in  current  RMS  a  different  unit  has  the  same  ready-made  MIS 
which  is  developed  in  the  highest  echelon.  Because  the  current  MIS  was  developed  to 
be  suitable  for  Army  division  level,  the  Korea  Army  has  experienced  many  difficulties 
in  applying  the  current  MIS  to  the  different  kind  of  unit. 

Similarly,  because  each  unit  does  not  have  the  specific  and  well-developed 
analysis  models,  there  is  no  way  to  compare  the  performance  of  each  unit  to  the  other. 
In  order  to  compare  and  evaluate  the  performance,  each  unit  must  have  its  own  MIS 
and  data  analysis  models  that  is  possible  to  get  the  useful  information  for  decision 
making. 

2.  Financial  Data  and  Operational  Data 

Management  information  helps  the  resource  manager  of  each  unit  to  make  the 
best  decision  and  it  is  produced,  processed,  and  used  through  MIS.  Management 
information  can  be  divided  into  two  classes:  financial  data  and  operational  data.  The 
Korea  Army  gets  the  financial  data  through  the  management  accounting  and  can 
obtain  the  operational  data  by  using  or  applying  statistical  theories  and  techniques. 

The  operational  data  is,  in  a  sense,  more  important  than  the  financial  data, 
because  it  is  closely  related  to  a  more  effective  measurement  -  combat  material 
readiness  and  availability.  However,  the  current  RMS  does  not  provide  sufficient 
operational  data  even  though  the  Korea  Army  has  a  requirement  to  maintain  the 
reliable  operational  data  which  can  explain  the  activities  or  purposes  of  the 
expenditure. 

Data  analysis  models  could  not  be  developed  without  sufficient  and  reliable 
operational  data.  Furthermore,  the  combat  material  readiness  and  availability  could 
not  be  measured  well  without  the  data  analysis  models.  This  problem  was  moreover 
complicated  by  using  a  unified  single  format  RTS  to  record  all  the  resource  expenditure 
data  of  the  unit  which  is  discussed  next  paragraph. 

3.  Resource  Transaction  Slip  (RTS) 

RTS  was  designed  to  collect  and  accumulate  all  the  data  about  the  uses  of 
each  unit  resources  by  the  Defense  Budget  Revolution  Committee,  but  it  contains 
intrinsic  problems  in  its  use. 

An  Army  division  has  seven  classes  of  floating  assets  by  and  large:  (1)  cash, 
(2)  foods,  (3)  petroleum  &  oil,  (4)  ammunitions,  (5)  repair  parts,  (6)  individual 
maintenance  materials,  &  (7)  troop  maintenance  materials.  The  expenditures  and 
transactions  activities  on  each  resources  should  be  recorded  in  a  separate  relation, 


32 


according  to  its  unique  characteristics.  However,  the  7  categories  of  the  resources  are 
required  to  be  recorded  in  the  single  format  of  RTS. 

The  RTS  has  only  30  items  to  be  described.  The  30  items  can  not  include  all 
the  facts  that  are  needed  to  process  information  for  decision  making.  Only  a  few  Of  30 
items  are  actually  used  in  recording  one  transaction  or  activity  of  the  resources,  that  is, 
the  rest  of  30  items  is  not  necessary  and  redundant. 

With  the  current  RTS,  it  is  impossible  to  calculate  all  the  training  expenses 
including  petroleum  &  oil,  repair  parts,  individual  or  troop  maintenance  materials, 
ammunitions,  and  cash  that  are  used  in  the  regiment  combat  training  (RCT). 
Additionally,  it  is  impossible  to  know  the  operational  performance  of  the  various 
vehicles  of  each  unit,  and  to  accumulate  the  operating  expenses  of  each  unit  facilities. 

The  RTS  is  the  source  of  all  the  data  needed  in  the  resource  management 
system.  However,  the  data  gathered  by  the  RTS  are  not  entirely  useful  for  the 
performance  evaluation,  problem  identification,  retirement  decision  of  a  equipment, 
and  readiness  or  availablity  measurement  of  each  unit.  Data  do  not  have  any  value  in 
themselves,  but  the  value  is  determined  depending  upon  the  objective  of  data  and  how 
they  are  used  in  the  analytical  models. 

In  order  to  acquire  the  most  useful  information  for  decision  making,  the 
analytical  models  are  developed  and  established,  but  more  important  thing  is  to 
analyze  the  data  requirement.  Therefore,  the  RTS  should  be  redesigned  to  meet  the 
information  requirement  resulting  from  the  proper  analysis  of  data  requirement. 

E.       SUMMARY 

The  Republic  of  Korean  Military  has  begun  to  recognize  the  need  for  budget 
revolution  because  the  U.S.  Military  Aid  Program  has  greatly  diminished  since  1970's. 
It  has  adopted  a  newly  designed  defense  resource  management  system  (DRMS).  The 
objective  of  DRMS  is  to  achieve  efficiency  and  effectiveness  in  military  spending  by  the 
use  of  a  newly-designed  PPBEES,  new  staff  structure,  modern  financial  accounting 
techniques,  program  management  system,  management  information  system,  and  a  new 
organizational  approach. 

In  this  chapter  we  have  reviewed  the  new  DRMS  implemented  completely  at  the 
beginning  of  fiscal  year  1986  and  discovered  the  limitations  of  DRMS;  (1)  negligence  of 
operational  data  that  is  indispensable  for  analysis  and  evaluation  system,  (2)  unsuitable 
and  insufficient  data  collection  method,  and  (2)  no  data  analysis  models,  caused  by  the 
insufficient  preparations  and  inexperiences.  Because  of  those  limitations,  the  current 
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DRMS  could  hardly  meet  the  initial  purpose  which  was  to  create  the  performance 
criteria  and  decision-making  information  for  each  unit's  efficiency  and  effectiveness 
mentioned  above.  This  background  will  aid  in  understanding  the  main  point  of  this 
paper:  The  database  approach  of  DRMS  at  ROK  Army  division  level. 

The  next  chapter  will  develop  the  information  requirement  of  ROK  Army 
resource  management  system  which  is  able  to  achieve  the  original  goals  of  DRMS.  The 
information  requirement  must  be  analyzed  to  meet  all  the  needs  of  current 
management  information  system  and  data  analysis  models  that  will  be  developed  in  the 
future. 
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III.  INFORMATION  REQUIREMENT  FOR  THE  DRMS  OF  ROK  ARMY 

A.       CONCEPTS    AND    PROCEDURES    OF    INFORMATION    REQUIREMENT 
DETERMINATION 

Correct  and  complete  information  requirements  are  key  ingredients  in  planning 
organizational  information  systems,  implementing  information  systems  applications, 
and  building  databases.  Major  information  system  applications  integrated  with 
databases  require  careful  planning  and  significant  cooperative  effort  between  users  and 
information  system  professionals. 

Information  requirement  determination  is  a  vital  part  of  this  cooperative  activity. 
Although  users  are  the  fundamental  source  of  requirements,  they  often  lack  the 
experience  to  accurately  define  them.  Inexperienced  analysts  often  feel  that  users 
should  tell  them  what  the  information  requirements  are  so  system  design  and 
implementation  can  be  developed.  Experienced  analysts  know  that  eliciting  correct  and 
complete  requirements  is  one  of  their  most  challenging  tasks. 

Since  a  database  management  system  must  ultimately  provide  service  for  end 
users,  careful  attention  should  be  given  to  their  needs.  The  users  may  be  anyone 
outside  the  organization,  operational  management,  high  level  management,  or  any 
combination  of  these.  Interviews  with  the  users  should  be  done  during  the  design  stage 
and  also  when  the  first  phases  of  implementation  are  completed  to  solicit  feedback  for 
modification  of  the  system.  If  the  data  base  management  system  does  not  meet  the 
user's  needs,  then  it  will  fail  no  matter  how  clever  and  sophisticated  the  technical 
design. 

Information  requirements  are  required  at  the  organization-wide  level  for 
information  system  planning,  identifying  applications,  and  planning  an  information 
architecture.  More  detailed  information  requirements  are  required  for  design  of 
applications. 

How  can  accurate  and  complete  information  requirements  be  identified?  Because 
of  the  constraints  on  humans  as  specifiers  of  information  requirements,  the  users  can 
not  identify  them  all.  Eliciting  correct  and  complete  requirements  is  one  of  the  most 
challenging  tasks.  Both  users  and  analysts  should  better  understand  the  process  of 
determining  information  requirements  and  improve  their  performance  in  this  area. 
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An  information  system  should  meet  the  needs  of  the  organization  it  serves,  and 
applications  should  meet  the  needs  of  their  users.  The  requirements  for  the  information 
system  are  therefore  determined  by  the  strategies,  goals,  procedures,  and  behavior  of 
individuals  within  the  organization  acting  individually  and  collectively.  [Ref.  10:  p. 
474]. 

In  order  to  effectively  analyze  organizational  information  requirements,  a  four 
step  process  is  presented: 

1.  Three  level  of  information  requirements 

2.  Analysis  of  organizational  information  requirements 

3.  Strategies  for  determining  information  requirements 

4.  Selecting  a  strategy  for  determining  information  requirements 

1.  The  Three  Levels  of  Information  Requirements 

There   are    three   levels    at   which   information   requirements   needs    to    be 
established  in  order  to  design  and  implement  computer-based  information  system: 

a.  The  organizational  information  requirements  to  define  an  overall  information 
system  structure  and  to  specify  a  portfolio  of  applications  and  databases. 

b.  The    requirements    for    each    database    defmed    by    data    models    and    other 
specifications. 

c.  The  detailed  information  requirements  for  an  application. 

a.  Organizational- Level  Information  Requirements 

Information  requirements  determination  at  the  organizational  level  is  a  key 
element  in  developing  an  information  system  master  plan.  The  process  of 
organizational  level  information  requirements  determination  obtains,  organizes,  and 
documents  a  complete  set  of  high-level  requirements.  The  requirements  are  factored 
into  databases  and  subsystems  that  can  be  scheduled  for  development.  The  overall 
information  architecture  is  defined,  and  the  boundaries  and  interfaces  of  the  individual 
application  subsystems  are  specified. 

b.  Database  Requirements 

Database  requirements  arise  both  from  applications  and  ad  hoc  queries. 
The  overall  architecture  for  the  databases  to  meet  these  requirements  can  be  defined  as 
parts  of  organizational  information  requirements.  Major  classes  of  data  are  defined 
and  associated  with  organizational  processes  that  require  them.  There  is  very  little 
detail  in  the  requirements  at  this  level. 
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The  process  of  obtaining  and  organizing  more  detailed  database 
requirements  can  be  divided  into  defining  data  requirements  as  perceived  by  the  users 
and  defining  requirements  for  physical  design  of  the  databases.  User  requirements  are 
referred  to  as  conceptual  or  logical  requirements  because  the  user  views  of  data  are 
separated  from  the  organization  of  data  in  physical  storage.  User  requirements  may  be 
derived  from  existing  applications  or  by  data  modeling. 
c.   Application- Level  Information  Requirements 

An  application  is  a  subsystem  of  the  overall  information  system  structure; 
it  provides  information  processing  for  an  organizational  unit  or  organizational  activity. 
The  process  for  the  determination  of  information  requirements  at  the  application  level 
defines  and  documents  specific  information  content  plus  design  and  implementation 
requirements. 

There  are  two  types  of  information  system  application  requirements:  social 
and  technical.  The  social  or  behavioral  requirements,  based  on  job  design,  specify 
objectives  and  assumptions  such  as  the  following: 

•  Work  organization  design  objectives 

•  Individual  role  assumptions 

•  Responsibility  assumptions 

•  Organizational  policies 

The  technical  requirements  are  based  on  the  information  needed  for  the  job 
or  task,  to  be  performed.  They  specify  outputs,  stored  data,  and  information  processes. 
A  significant  part  of  the  technical  requirements  are  associated  with  the  structure  and 
format  of  data.  The  technical  requirements  include  interface  requirements  between  the 
user  system  and  the  application  system.  The  interface  requirements  include  data 
presentation  format,  screen  design,  user  language  structure,  feedback  and  assistance 
provisions,  error  control,  and  response  time.  [Ref.  10:  pp.  475  -  476]. 
2.  Analysis  of  Organizational  Information  requirements 

Once  goals  and  strategy  have  been  delineated,  the  next  stage  is  to  obtain 
organizational  information  requirements.  Although  the  level  of  specification  is  different 
for  the  organization  and  application,  many  of  the  methods  for  obtaining  requirements 
are  the  same.  Obtaining  organizational  information  requirements  consists  of  several 
steps: 

a.  Define  underlying  organizational  subsystems 

b.  Develop  manager  by  subsystem  matrix 

c.  Define  and  evaluate  information  requirements  for  organizational  subsystems 
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a.  Define  Underlying  Organizational  subsystems 

The  first  phase  of  analysis  is  to  define  underlying  organizational 
subsystems.  The  purposes  of  activity  subsystem  identification  is  to  subdivide 
requirements  determination  by  major  organizational  activity  and  make  the  process 
more  manageable.  The  subsystems  are  obtained  by  an  iterative  process  of  discussing  all 
organizational  activities  with  managers  and  defining  the  activities  as  belonging  to 
broad  categories  of  subsystems.  As  new  activities  are  considered,  they  are  placed  in 
previously  defined  categories,  or  a  new  category  is  created. 

b.  Develop  Subsystem-manager  Matrix 

Once  the  underlying  organizational  subsystems  are  defmed,  the  next  phase 
of  the  organizational  information  requirements  analysis  is  to  relate  specific  managers  to 
organizational  subsystems.  The  matrix  is  prepared  by  reviewing  the  major  decision 
responsibilities  of  each  middle  to  top  level  manager  and  associating  decision  making 
with  specific  subsystems.  The  matrix  identifies  the  major  decision-making 
responsibilities  for  each  subsystem.  The  purpose  of  this  step  is  to  clarify  responsibilities 
and  identify  those  managers  to  be  interviewed  relative  to  each  subsystem. 

c.  Define  and  Evaluate  Information  Requirements  for  Organizational  Subsystems 
This  step  obtains  the  information  requirements  of  each  organizational 

subsystem  by  group  interviews  of  those  managers  having  major  decision-making 
responsibility  for  the  subsystem.  Merely  asking  managers  to  define  their  information 
requirements  is  frequently  not  satisfactory  because  of  the  limitations  on  humans  as 
information  processors.  It  is  therefore  necessary  to  provide  some  structure  to  aid 
managers  in  thinking  about  information  requirements. 

The  questions  used  in  eliciting  information  requirements  are  derived  from 
three  approachs.  These  questions  reflect  three  ways  of  thinking  about  requirements, 
but  each  question  also  delineates  unique  requirements.  The  use  of  the  three  types  of 
questions  therefore  increases  the  probability  of  obtaining  a  complete  set  of 
requirements.  The  three  questions  are: 

•  What  problems  do  you  have  and  what  information  is  needed  for  solving  them? 
What  decisions  do  you  make  and  what  information  do  you  need  for  decision 
making? 

•  What  factors  are  critical  to  the  success  of  your  activity  and  what  information 
do  you  need  to  achieve  success  in  them  or  monitor  progress? 

•  What  are  the  outputs  (the  ends)  from  your  activities  and  what  information  do 
you  need  to  measure  effectiveness  in  achieving  the  outputs?  What  resources  are 


38 


used  in  producing  the  outputs  and  what  information  is  needed  to  measure  the 
efficient  use  of  resources?  [Ref.  10:  pp.  460  -  462] 

3.  Strategies  for  Determining  Information  Requirements 

A  strategy  was  defined  as  an  approach  for  achieving  an  objective.  There  are 
four  strategies  for  determining  information  requirements: 

a.  Asking  directly 

b.  Deriving  from  an  existing  information  system 

c.  Synthesizing  from  characteristics  of  the  utilizing  system 

d.  Discovering  from  experimentation  with  an  evolving  information  system 

a.  Asking  Directly 

In  an  asking  directly  strategy,  the  analyst  obtains  information  requirements 
from  persons  in  the  utilizing  system  solely  by  asking  them  what  their  requirements  are. 
From  a  conceptual  standpoint,  the  asking  directly  strategy  assumes  that  users  can 
structure  their  problem  space  and  overcome  or  compensate  for  biases  due  to 
concreteness,  recency,  small  sample  size,  and  unused  data.  Anchoring  by  users  in 
formulating  responses  is  assumed  to  yield  satisfactory  results.  These  conditions  may 
hold  in  very  stable  systems  for  which  a  well-defined  structure  exists  or  in  systems 
whose  structure  is  established  by  law,  regulation,  or  other  outside  authority.  There  are 
a  variety  of  methods  for  carrying  out  an  asking  strategy. 

If  a  pure  asking  directly  strategy  is  followed,  one  or  more  asking  methods 
are  used  to  elicit  requirements,  and  analysis  is  limited  to  consistency  checks  as 
requirements  are  documented,  the  asking  methods  can  also  be  used  in  conjunction  with 
other  strategies. 

b.  Deriving  from  an  Existing  Information  System 

Existing  information  systems  with  an  operational  history  can  be  used  to 
derive  requirements  for  a  proposed  information  system  for  the  same  type  of 
organization  or  application.  Types  of  existing  information  systems  that  are  useful  in 
deriving  requirements  for  future  systems  are: 

•  Existing  system  that  will  be  replaced  by  the  new  system 

•  Existing  system  in  a  similar  organization 

•  Propriety  system  or  package 

•  Descriptions  in  textbooks,  handbooks,  industry  studies,  etc. 

With  regard  to  human  problem-solving  behavior,  deriving  from  an  existing 
information  system  is  an  explicit  use  of  anchoring  and  adjustment.  Users  and  analysts 
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explicitly  choose  an  existing  system  as  an  anchoring  and  adjust  the  requirements  from 
it.  Driving  information  requirements  from  an  existing  information  system  has  also  been 
termed  a  data  analysis  approach  since  the  data  inputs  and  outputs  of  the  existing 
system  are  the  focus  of  analysis. 

If  the  information  system  is  performing  fairly  standard  operations  and 
providing  fairly  standard  information  for  stable  utilizing  systems,  the  use  of  an  existing 
system  as  an  anchor  is  appropriate.  In  application  systems  for  some  well-defined 
functions  such  as  payroll,  data  analysis  of  an  existing  system  can  be  a  useful  primary 
method.  In  the  early  application  of  computers  to  organizational  transaction  processing 
and  accounting  system,  derivation  of  requirements  from  the  processing  performed  on 
the  data  provided  by  the  existing  system  was  widely  used. 

Some  analysts  use  data  analysis  of  the  existing  system  as  a  secondary 
method  for  deriving  requirements.  To  avoid  being  overly  influenced  by  the  concreteness 
of  the  existing  system,  they  may  delay  its  use  until  after  their  primary  analysis  method 
has  provided  an  initial  set  of  requirements. 

c.  Synthesis  front  Characteristics  of  the  Utilizing  System 

Information  systems  provide  information  services  to  facilitate  the  operation 
of  object  systems,  those  that  utilize  the  information.  Requirements  for  information 
thus  stems  from  the  activities  of  the  object  system.  This  suggests  that  the  most  logical 
and  complete  method  for  obtaining  information  requirements  is  from  an  analysis  of  the 
characteristics  of  the  utilizing  system.  This  approach  may  overcome  biases  by  providing 
an  analytical  structure  for  the  problem  space  of  the  user  or  analysts.  The  object  system 
analysis  is  therefore  appropriate  when  the  utilizing  system  is  changing  or  the  proposed 
information  system  is  different  from  existing  patterns  (in  its  content,  form,  complexity, 
etc.),  so  that  anchoring  on  an  existing  information  system  or  existing  observations  of 
information  needs  will  not  yield  a  complete  and  correct  set  of  requirements. 

d.  Discovering  from  Experimentation  with  an  Evolving  Information  System 
Traditional    procedures    for    determining    information    requirements    are 

designed  to  establish  a  complete  and  correct  set  of  requirements  before  the  information 
system  is  designed  and  built.  In  a  significant  percentage  of  cases,  users  may  not  be  able 
to  formulate  information  requirements  because  they  have  no  existing  models  on  which 
to  base  requirements.  They  may  find  it  difficult  to  deal  in  abstract  requirements  or  to 
visualize  new  systems.  Users  may  need  to  anchor  on  concrete  systems  from  which  they 
can  make  adjustments. 
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Another  approach  to  information  requirements  determination  is,  therefore, 
to  capture  an  initial  set  of  requirements  and  implement  an  information  system  to 
provide  those  requirements.  The  system  is  designed  for  ease  of  change.  As  users  employ 
the  system,  they  request  additional  requirements.  After  initial  requirements  establish  an 
anchor,  additional  requirements  are  discovered  through  use  of  the  system.  The  general 
approach  has  been  described  as  prototyping  or  heuristic  development.  [Ref.  10:  pp. 
480  -  488] 

4.  Selecting  a  Strategy  for  Determining  Information  Requirements 

Four  strategies  have  been  described  for  determining  information  requirements, 
with  each  strategy  having  a  number  of  methods  that  may  be  employed.  The  selection 
procedure  is  contingent  on  characteristics  of  the  environment  in  which  the 
determination  of  requirements  is  conducted. 

The  underlying  basis  for  selecting  a  strategy  is  uncertainty  with  respect  to  the 
requirements  determination  processes.  The  uncertainty  is  based  on  four  factors: 
characteristics  of  the  utilizing  system,  the  information  system  or  application,  the  users, 
and  the  analysts. 

The  approach  to  selecting  an  information  requirements  determination  strategy 
consists  of  five  steps  as  shown  in  Figure  3.1.   [Ref.  10:  p.  489] 

The  steps  represent  a  series  of  evaluations  to  establish  a  basis  for  selection. 
The  evaluations  are  not  precise,  but  do  provide  guidelines  for  judgment.  The  steps  are 
listed  as  follows. 

1)  Identify  those  characteristics  of  the  four  elements  in  the  development  process 
that  affect  uncertainty  in  the  determination  of  information  requirements: 

•  Utilizing  system 

•  Information  system  or  application 

•  Users 

•  Analysts 

2)  Evaluate    the    effect    of  the   characteristics    of  the    four   elements    in   the 
development  process  on  three  process  uncertainties: 

•  Existence  and  availability  of  a  set  of  usable  requirements 

•  Ability  of  users  to  specify  requirements 

•  Ability  of  analysts  to  elicit  and  evaluate  requirements 

3)  Evaluate    the    combined    effect    of   the    process    uncertainties    on    overall 
requirements  uncertainty. 
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4)  Select  a  primary  strategy  for  requirements  determination  based  on  the  overall 
requirements  uncertainty. 

5)  Select  one  or  more  methods  from  the  set  of  methods  to  implement  the  primary 
strategy.  [Ref.  10:  p.  490] 

B.       INFORMATION  REQUIREMENTS  FOR  DRMS  OF  ROK  ARMY  DIVISION 
LEVEL 

As  we  mentioned  in  the  previous  chapter,  the  Defense  Budget  Revolution 
Committee  was  established  in  order  to  make  an  intrinsic  improvement  in  the  defense 
budget  system.  The  committee  selected  eight  major  functions  to  implement  the 
PPBEES  system:  1)  decision  making  process;  2)  planning  programming  process;  3) 
project  management  system;  4)  decentralized  management  system;  5)  computer-based 
management  information  system;  6)  analysis  and  evaluation  system;  7)  resource 
management  staff  function;  and  8)  reorganization. 

Among  the  eight  major  functions,  decentralized  management  system  is  considered 
as  the  most  important  and  critical  function  at  the  army  division  level.  A  decentralized 
management  system  leads  a  resource  manager  (commanding  officer)  to  improve  the 
efficiency  and  effectiveness  of  all  the  resource  utilizations  and  produce  various  data 
credibly  that  high-level  units  need. 

Because  management  means  a  boundless  decision-making  process  and  the 
decision  making  is  based  on  the  proper  information,  a  decentralized  management 
system  depends  heavily  upon  the  quality  of  management  information  system  of  an 
army  division.  The  information  and  data  are  only  of  use  when  they  are  used  in  decision 
making.  The  data  gathered  without  considering  the  users'  needs,  evaluation  criteria, 
and  decision  support  models  will  not  provide  useful  information.  While  this  type  of 
data  is  "nice-to-know",  it  is  of  no  use  as  an  aid  to  analysis  or  decision  making.  The 
information  which  army  division  as  a  resource  management  unit  should  produce  for  its 
own  use  and  high-level  unit's  needs  may  differ  according  to  the  type  or  kind  of  decision 
making,  that  is,  different  kinds  of  decision  making  requires  different  information. 

Decision  making  may  be  conducted  by  rule  of  thumb  from  data  gathered  in  the 
simple  cases,  but  in  the  more  complicated  cases  a  decision  support  model  must  be  used 
to  get  useful  information  for  decision  making.  Therefore,  data  gathered  should  be 
suitable  for  the  decision  support  models  or  data  analysis  models. 

The  major  premise  of  the  decentralized  management  system  is  performance 
measure.  Fair  performance  major  is  the  best  tool  to  motivate  the  resource  manager  of 
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each  unit.  Resource  manager's  behaviors  may  be  changed  according  to  the 
performance  criteria  (motivation  device)  that  will  be  decided.  Resource  managers  may 
operate  and  lead  their  unit  to  be  evaluated  their  performances  highly  comparing  to  the 
established  performance  criteria.  Therefore,  in  order  to  determine  correct  and  complete 
information  requirements,  decision-making  types,  decision  support  models,  and 
performance  criteria  should  be  selected  before  anything  else.  The  analysis  of 
information  requirement  determination  is  the  most  important  step  in  structuring  the 
management  information  system. 

The  requirements  for  routine  transaction  processing  at  the  army  division  level 
might  be  stable  and  relatively  easy  to  identify.  However,  informantion  requirements  for 
management  and  decision  making  activities  would  be  more  changeable  and  more 
difficult  to  define.  To  identify  current  and  complete  information  requirements  at  the 
army  division  level,  it  is  rational  to  survey  or  interview  the  various  in  each  functional 
group:  the  asking  directly  strategy  is  suitable  for  determining  information  requirements 
at  the  army  division  level. 

1.  General  Information  Requirements 

In  the  previous  chapter,  we  identified  the  limitations  of  defense  resource 
management  system  (DRMS);  (1)  negligence  of  operational  data  that  is  indispensable 
for  analysis  and  evaluation  system,  (2)  unsuitable  and  insufficient  data  collection 
methods,  and  (3)  no  decision  support  models.  To  overcome  those  limitations  of 
DRMS,  the  authors  try  to  change  the  data  collection  methods  based  on  new 
information  requirements,  build  the  database  of  DRMS  at  the  army  division  level,  and 
encourage  development  of  the  decision  support  models  in  order  to  meet  the  initial 
objective  of  DRMS. 

As  mentioned  above,  the  information  requirement  determination  is  the  critical 
step.  The  information  requirements  must  meet  the  needs  of  all  kinds  of  decision 
making,  performance  measures,  decision  support  models,  and  existing  information 
systems.  In  order  to  meet  these  needs,  we  developed  general  information  requirements 
for  the  army  division  level.  They  are  the  information  requirements  that  should  be 
accepted  in  the  future  to  achieve  the  objective  of  DRMS  at  the  army  division  level. 

The  general  information  requirements  created  by  authors  are  listed  and 
explained  as  follows: 

a)  Evaluation  of  each  responsible  manager's  performance. 

b)  Calculation  of  the  expense  of  each  unit  activity. 

c)  Measurement  of  each  training  costs. 
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d)  Derive  the  expense  coefficient  of  each  equipment  per  operating  hour. 

e)  Accumulate  the  operating  and  maintenance  cost  of  each  equipment  by  each 
model  and  each  production  year. 

f)  Estimation  of  the  life  cycle  cost  of  combat  urgent  equipment. 

g)  Measurement  of  the  changes  in  inventory  of  each  unit, 
h)       Calculation  of  the  logistic  support  capability. 

i)        Production  of  the  other  data  for  availability  and  combat  readiness. 

a.  Evaluation  of  Responsible  manager's  performance 

To  increase  the  efficiency  and  effectiveness,  each  responsible  manager's 
performance  is  evaluated  and  compared  with  the  other  managers.  The  performance 
criteria  must  be  developed  to  conduct  a  performance  measure  of  each  responsible  unit. 
Information  requirements  for  evaluating  each  responsible  manager's  performance  must 
be  included  in  the  newly  designed  database  system  (  called  new  system  below). 

b.  Calculation  of  Expenses  of  Each  Unit  Activity 

This  calculation  of  the  expenses  of  each  activity  also  will  provide  useful 
information  for  commanding  officers  about  how  the  defense  resources  should  be 
allocated  to  maximize  the  effectiveness  of  resource  utilization  in  each  activity.  The 
expenses  of  each  activity  should  be  collected  to  two  classes;  fixed  expenses  and  variable 
expenses  and  we  must  derive  the  types  of  relationships  among  them. 

c.  Measurement  of  Each  Training  Costs 

The  objective  of  measurement  of  each  training  costs  (i.e.,  petroleum  &  oil, 
repair  parts,  materials,  cash  etc.)  can  induce  resource  managers  to  consider  the  cost- 
benefit  analysis  of  each  training.  Training  cost  may  differ  depending  upon  the 
characteristics  of  each  unit  and  regional  conditions.  Therefore,  the  measurement  of 
each  training  cost  will  provide  a  criterion  for  each  unit  and  each  training  in  budgeting, 
allocating  resources,  and  forecasting  war  time  minimal  resource  requirements. 

d.  Production  of  the  Expense  Coefficient  of  Each  Equipment 

By  using  multiple  regression  technique,  we  can  derive  the  expense 
coefficient  of  each  equipment  used  in  different  activity  or  objective.  The  expense 
coefficient  can  become  a  useful  tool  for  finding  out  the  recording  errors  in  recording 
the  expense  of  each  equipment,  a  indicator  that  can  shows  the  differences  between  each 
unit  and  each  activity  in  operating  equipments,  and  a  useful  criterion  for  selecting  an 
optimal  equipment. 


Expense  coefficient  is  defined  as  the  unit  impact  of  each  equipment  on  defense 
resources  explained  in  detail  in  Chapter  VI. 
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e.  Measurement  of  O&M  cost  of  each  equipment 

One  of  the  important  policies  in  managing  the  organized  equipment  is  to 
determine  the  economic  repair  limitation  and  the  reasonable  retirement  time  of  each 
equipment.  To  do  these,  we  need  the  data  about  the  operating  and  maintenance  costs 
of  each  equipment.  Although  this  data  may  be  used  at  a  level  higher  than  the  resource 
management  unit,  the  data  must  be  gathered  by  the  unit  that  operates  the  equipment. 
In  the  current  system,  this  data  is  not  gathered  from  the  operating  units  directly  and 
currently  not  required.  But,  this  data  must  be  gathered  from  the  unit  fields  and 
required  in  the  new  system. 

f.  Estimate  of  LCC  of  Combat  Urgent  Equipment 

The  cost  of  combat  urgent  equipment  is  very  expensive  relative  to  other 
equipment.  The  estimate  of  life  cycle  cost  (LCC)  of  each  combat  urgent  equipment  can 
provide  a  useful  information  in  measuring  the  availability  or  combat  readiness, 
forecasting  the  demands  of  combat  equipment,  and  developing  the  adequate  supply 
package  of  repair  parts  in  war  or  peace  time. 

g.  Inventory  Management 

To  increase  the  efficiency  and  effectiveness  in  inventory  management, 
inventory  management  models  (i.e.,  EOQ:  economic  order  quantity  model)  should  be 
developed  and  a  systemic  device  for  controlling  inventory  transaction  and  finding  out 
changes  in  inventory  should  be  structured. 

h.   Calculation  of  facility  maintenance  costs 

The  analysis  of  facility  maintenance  costs  also  give  decision  makers  useful 
information  in  planning  and  budgeting  the  total  facility  maintenance  costs.  We  can  get 
the  standard  maintenance  cost  per  square  meter  for  each  facility  from  analysis  of 
maintenance  expenses. 

I.   Evaluation  of  Logistic  Support  Capability 

A  supply  supported  unit  (army  division  level)  must  evaluate  the  logistic 
support  capability  (i.e.,  stockout  items,  supply  lead  time,  unused  materials,  repair  parts 
purchased  from  the  civilian  etc.)  of  the  supply  supporting  unit  (logistic  command).  By 
doing  so,  a  supply  supported  unit  can  take  reasonable  actions  to  convert  into  a  rapid 
supply  system  and  be  able  to  solve  anticipated  problems  in  war  and  peace  time. 
2.  Output  Data  List  Based  on  Information  Requirements 

Based  on  the  general  information  requirements,  the  input  data,  processing 
models/ software  programs,  and  output  formats  will  be  determined.  Output  documents 
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produced  by  the  new  system  will  be  based  heavily  on  the  general  information 
requirements  and  contain  the  detailed  information  for  decision  making.  They  will  be 
produced  by  data  process  associated  with  materials,  cash  transaction,  and  resource 
utilization  in  the  computer  system. 

Output  documents  will  be  classified  into  two  classes;  reports  forwarded 
upward  (external  documents)  and  reports  used  inside  (internal  documents).  External 
documents  are  reported  to  higher  echelon,  and  are  used  in  planning,  programming, 
budgeting,  and  controlling  defense  resources.  External  documents  are  well  developed  in 
the  current  system  as  discussed  in  the  previous  chapter. 

Unfortunately,  the  current  system  of  internal  reporting  is  underdeveloped. 
Internal  reports  generated  by  the  new  system  consist  of  useful  information  with  which 
the  commanding  officers  and  staffs  can  manage  the  defense  resources  efficiently. 

In  this  paper,  we  will  place  their  emphasis  on  the  documents  which  are  utilized 
within  the  army  division  level  in  order  to  assess  management  performance  and 
stewardship,  to  get  information  on  program  activity  and  fiscal  compliance,  and  to 
determine  resource  allocations.  Internal  documents  are  created  by  authors  based  on 
the  general  information  requirements  discussed  above.  These  documents  are  listed  as 
shown  in  Table  3  and  are  divided  into  three  categories;  inflow  of  resources  and  changes 
in  inventory,  resource  utilization,  and  combat  readiness  measurement. 
3.  Specific  information  requirements 

The  timely,  accurate,  and  relevant  information  enable  management  to  evaluate 
management  performance,  to  determine  resource  allocation  and  to  make  good 
decisions.  To  get  timely,  accurate,  and  relevant  information,  the  authors  defined  first 
the  general  information  requirements  and  then  produced  the  documents  based  on  them. 
Now  the  authors  define  the  specific  (detail)  information  requirements  of  each  document 
that  will  satisfy  the  needs  of  management. 

The  authors  identify  the  subcategories  of  information  (data  elements)  and 
purpose  of  each  documents  in  Appendix  A. 
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TABLE  3 
NEWLY-CREATED  INTERNAL  DOCUMENTS 

Classification 

Document       Name 

Inflow  of 
resources  and 
changes  in 
inventory 

*  Unit  supply  transaction  &   assets 

*  Total  unit  resources  report 

*  Unit  changes  in  inventory  report 

*  Unit  resource  D  /  0   report 

Resource 
utilization 

*  Unit  activity  expense  report 

*  Unit  resource  utilization  report 

*  Budget  allocation  and  expenditure 

*  Cash  disbursement  report 

*  Cash  disbursement  by  activity 

*  Equip,  expense  coefficient  report 

*  Equip,  operation  by  activity 

*  Operating  performance  by  equipment 

*  Unit  training  cost  report 

*  Facility  maintenance  cost  report 

Combat  readiness 
measurement 

*  Combat  equipments 
average  life  analysis 

*  Supply  support  required  time 
analysis 

*  Inventory  stockout  report 

*  Combat  urgent  equipment  and 
repair  part  stockout  report 

C.       SUMMARY 

Information  requirement  determination  is  the  starting  point  in  planning  an 
organizational  information  system,  in  implementing  systems  applications,  and  in 
building  a  database.  To  determine  correct  and  complete  information  requirements, 
decision-making  types,  decision  support  models,  and  performance  criteria  should  be 
selected  before  determination  of  information  requirements. 

Unfortunately,  decision-making  types  and  decision  support  models  are  not  well 
defined  and  developed  at  the  ROK  Army  division  level.  Therefore,  the  authors 
determined  the  information  requirements  for  DRMS  at  the  army  division  level  based 
on  their  judgment  and  experiences. 
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The  new  system  which  will  be  redesigned  in  the  future  should  satisfy  the 
following  general  information  requirements: 

•  Evaluation  of  the  each  responsible  manager's  performance. 

•  Calculation  of  the  expense  of  each  unit  activity. 

•  Measurement  of  the  each  training  costs. 

•  Derivation  of  the  expense  coefficient  of  each  equipment  per  operating  hour. 

•  Accumulate  the  operating  and  maintenance  cost  of  each  equipment  by  each 
model  and  each  production  year. 

•  Estimation  of  the  life  cycle  cost  of  combat  urgent  equipment. 

•  Measurement  of  the  changes  in  inventory  of  each  unit. 

•  Calculation  of  the  logistic  support  capability. 

•  Production  of  the  other  data  for  availability  and  combat  readiness. 

Based  on  the  general  information  requirements,  the  authors  created  several 
internal  documents,  which  will  be  useful  for  commanding  officers  to  make  decisions. 
Data  contained  in  those  documents  can  provide  the  information  for  the  appropriate 
allocation  of  defense  resources,  give  performance  criteria  for  performance  measure  of 
each  unit,  and  encourage  to  develop  the  decision  support  models. 

The  next  two  chapters  will  discuss  the  design  and  manipulation  of  database  that 
will  make  it  possible  to  satisfy  the  information  requirements  of  DRMS  at  the  army 
division  level  and  to  overcome  the  limitations  of  current  DRMS  discussed  in  the 
previous  chapter. 
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IV.  REVIEW  OF  RELATIONAL  DATA  MANAGEMENT  APPROACH 

A.       DATA  MANAGEMENT  PHILOSOPHY 

Effective  management  of  organizations,  both  private  and  public,  depends  on 
information  concerning  the  organization's  operations,  finances,  and  the  allocation 
of  its  resources.  With  such  information  management  can  control  costs  and 
maximize  profits  or  operational  efficiency.  Such  information  also  provides  a  basis 
for  planning  for  future  developments,  i.e.,  new  services,  improved  operations. 
[Ref.  11:  p.  3] 

It  is  widely  recognized  that  data  is  the  most  valuable  resource  in  an  organization. 
Since  the  management  of  an  organization  requires  a  series  of  decision  making  activities, 
accurate  and  timely  data  plays  a  crucial  role  in  making  informed  decisions.  Data  must 
be  managed  systematically  to  meet  the  user's  needs;  this  is  the  cornerstone  of  the  data 
management  philosophy. 

1.  Data  as  a  Shared  resource 

The  scope  of  organizational  activities  is  very  broad  and  associated  with  the 
levels  of  management  and  functional  activities.  The  most  important  aspect  of 
management  activities  is  decision-making.  Information  requirements  vary  by 
management  level  and  organizational  function,  and  use  common  data  frequently. 

Each  functional  group  could  maintain  independently  the  data  unique  to  its 
decision  making,  however  this  might  result  in  data  redundancy  and  inconsistency  from 
a  global  viewpoint. 

The  ideal  condition  is  that  an  organization  shares  data  which  is  accessible  to 
different  users  for  different  purposes.  These  data  might  be  regarded  as  the  raw  material 
for  producing  meaningful  information.  This  view  supports  the  notion  that  information 
is  an  organizational  resource. 

2.  Data  Independence 

The  philosophy  of  data  independence  is  concerned  with  the  aspects  of  data 
storage  and  retrieval.  Data  independence  means  the  separation  of  the  user  view  of 
data  (logical  data  model)  from  the  physical  storage  of  data  (physical  data  model). 

When  data  independence  holds,  changes  in  either  data  model  are  possible 
without  affecting  the  other.  The  database  designer  or  user  is  allowed  to  change  the 
storage  structure  or  access  strategy  in  response  to  changing  requirements  without 
having  to  modifying  existing  applications. 
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Data  independence  is  extremely  desirable  because  it  potentially  increases  the 
applications  which  can  use  the  same  data.  If  data  is  dependent  on  the  application 
(program),  we  have  to  separately  create  and  maintain  the  data  used  in  each  case. 
However,  in  the  case  of  data  independence,  different  applications  can  use  different 
views  of  the  same  data. 

3.  Centralized  Control 

An  organization  needs  to  integrate  its  data  processing  system  with  centralized 
control.  If  there  are  no  integrating  mechanisms,  data  items  may  be  specified  differently 
and  cause  inconsistent  and  incompatible  descriptions.  There  may  also  be  redundant 
development  of  separate  applications  when  a  single  application  could  serve  as  well. 

Centralized  control  over  an  organization's  operational  data  provides  several 
advantages: 

Reduced  redundancy 

Consistency  of  application 

Improved  data  sharing 

Enforced  standards,  integrity,  and  security 

Reduced  conflicting  requirements  [Ref.  12:  pp.  10-12] 

B.       DATA  BASE  MANAGEMENT  SYSTEM  (DBMS) 

Data  needs  to  be  managed  systematically  in  order  to  be  available  to  the  user  in  a 
timely  and  accurate  manner.  A  DBMS  is  a  software  system  which  makes  the  database 
concept  operational. 

1.  Difference  between  DBMS  and  File  System 

Data  base  management  systems  can  be  distinguished  from  file  systems  by  the 
level  of  functions  they  provide,  as  well  as  the  degree  of  semantics  attributed  to  the 
data. 

a.   File  system 

A  file  system,  as  the  traditional  approach  to  data,  is  often  characterized  by 
data  redundancy  and  inconsistency. 

File  systems  may  also  obstruct  an  organization's  growing  demands  for 
diverse  application  programs,  because  the  practice  of  creating  and  maintaining  separate 
files  for  each  application  tends  to  store  no  more  data  than  are  needed  for  the  job  at 
hand. 


51 


For  user  access  and  data  integrity,  a  file  system  often  does  not  provide 
adequate  conditions.  It  stores  data  according  to  user-defined  formats  called  records, 
and  may  or  may  not  provide  a  directory  of  files  on  a  per-user  basis.  Users  share  data 
by  equally  ad  hoc  means,  generally  by  taking  turns  accessing  the  same  device. 
b.   Database  Management  System 

A  DBMS  provides  a  higher  level  of  functions  than  a  file  system: 

•  Contains  more  structured  data:  maximize  accessibility,  minimize  cost 

•  Provides  a  greater  degree  of  data  independence  from  the  physical  layout 

•  Supports  reliable  recovery  (back-up)  and  integrity 

•  Enables  interface  with  special  applications  or  ad  hoc  queries 

Besides,  users  interact  with  the  DBMS  through  language  subsets,  such  as  a 
data  definition  language  and  data  manipulation  language.   Most  DBMS  provide  a 
directory/ dictionary  at  a  higher,  more  user  oriented  level  than  file  systems  do.  These 
details  will  be  discussed  in  the  following  section. 
2.  Functions  of  DBMS 

Since  a  database  management  system  must  ultimately  serve  the  user's  needs, 
the  capabilities  of  DBMS  have  evolved  continuously  to  provide  a  significant  increase  in 
availability,  integrity,  and  consistency  of  data.  Table  4  lists  nine  major  DBMS 
functions  which  were  introduced  briefly  in  the  previous  section. 


TABLE  4 

FUNCTIONS  OF  DBMS 

•           Store,  retrieve,  and  update  data 

•           Provide  integrity  services 

•          Control  concurrent  processing 

•           Support  logical  transactions 

•           Recover  from  failure 

•           Provide  security  facilities 

•           Interact  with  communications  control 

programs 

•           Provide  utility  services 
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The  DBMS  must  store,  retrieve,  and  update  data.  In  addition,  the  DBMS 
should  provide  integrity  services  to  enforce  constraints  on  the  data. 

Maintaining  a  database  with  dozens  of  records  and  hundreds  of  data-items 
can  be  time  consuming.  Therefore,  the  usefulness  of  the  data  dictionary  is  increased  if 
it  contains  not  only  data  descriptions  but  also  relationships  between  programs  and 
data,  e.g.,  which  programs  access  which  data,  and  what  they  do  with  it. 

Since  a  data  base  is  a  shared  data  resource,  several  users  may  try  to  access  it 
simultaneously.  To  meet  this  situation,  the  DBMS  must  provide  controls  over 
concurrent  operations.  Actually,  concurrent  processing  is  not  simultaneous  because  no 
two  actions  take  place  at  the  same  time  in  a  single  CPU  or  DBMS.  The  DBMS 
controls  processes  which  must  be  interleaved  properly  in  order  to  preserve  the  correct 
data  values. 

A  logical  transaction  is  a  sequence  of  activities  performed  automatically. 
Usually,  transactions  include  several  actions  on  the  database.  However,  the  DBMS 
cannot  know  which  groups  of  actions  are  logically  related.  Thus  the  DBMS  must 
provide  facilities  for  the  application  program  to  define  transaction  boundaries. 

The  next  two  functions  were  already  discussed  in  the  previous  section  on  DB 
requirements.  The  DBMS  must  be  able  to  recover  from  failure,  such  as  machine 
failures,  disk  crashes,  berserk  programs,  and  unenlightened  users.  A  database  is  a 
valuable  resource  as  well  as  a  model  of  the  current  state  of  an  organization.  If  the 
database  is  divulged  to  improper  or  unauthorized  people,  considerable  damage  can 
occur.  To  reduce  the  likelihood  of  such  loss,  the  DBMS  provides  security  facilities  by 
which  users  can  be  defined  and  identified  and  authorization  enforced. 

Additionally,  the  DBMS  must  interface  with  a  communications  processing 
system.  Terminal  users  interact  with  a  communications  control  program,  which 
controls  the  flow  of  transactions  to  application  programs  which  then  call  upon  the 
DBMS.  The  final  function  of  utility  service  is  to  facilitate  database  maintenance. 
People  may  not  follow  established  procedures,  and  it  may  be  necessary  to  determine  if 
one  copy  of  a  database  is  identical  to  another.  Also  there  may  be  a  need  to  make  mass 
insertions  or  deletions  of  data  in  or  out  of  the  database.  [Ref.  13:  pp.  401-406] 
3.  DBMS-related  Subsystems 

a.   Data  dictionary  I  directory  system  (DDfDS) 

The  DD/DS  provides  effective  centralized  control  of  organization  data 
resources  in  a  uniform  manner. 
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A  data  dictionary,  as  a  repository  of  information  about  data,  represents  a 
description  of  data  stored  in  the  database.  The  main  information  contained  in  the  data 
dictionary  includes  the  following: 
Name  of  the  data  item 
A  description  of  the  data  item 
Source  of  data 
Impact  analysis 

Key  words  used  for  categorizing  and  searching  for  data  item  descriptions 
[Ref.  10:  p.  505] 

The  directory  contains  a  physical  map  of  the  objects  it  stores  ('where'  and 
'how'),  including  the  external  name  object,  its  characteristics,  the  authorization  users 
have  on  it,  and  its  relationships  with  or  dependencies  on  other  objects. 

The  major  objective  of  a  DD/DS  is  to  support  the  integration  of  metadata4 
in  much  the  same  way  that  a  DBMS  supports  the  integration  of  an  organization's  data. 
The  benefits  achieved  from  the  data  dictionary  are  minimum  redundancy,  consistency, 
standardization,  and  metadata  sharing.  In  addition,  the  integration  of  data  describing 
the  database  allows  the  database  administrator  (DBA)  to  monitor  data  base  content 
and  to  effectively  enforce  security  and  integrity  policies. 
b.   Database  Query  Language 

Query  languages  are  specific  to  the  database  management  system  with 
which  they  are  used.  Each  data  base  management  system  has  its  own  query  language 
with  unique  rules  and  instruction  formats. 

Two  usages  of  a  data  query  language  are  for  data  processing  and  reporting 
applications,  and  ad  hoc  queries.  The  first  case  is  oriented  to  programmers,  such  as 
COBOL,  whereas  ad  hoc  queries  are  sufficiently  simple  that  they  can  be  made  by  non- 
programmers. 

The  most  well  known  query  language  for  relational  systems  is  SQL 
(structured  query  language).  SQL  is  a  transform-oriented  relational  language  which 
includes  commands  for  data  definition,  data  manipulation,  and  data  control.  In  the 
next  chapter,  examples  of  data  manipulation  using  SQL  will  be  presented. 


4Data  about  the  data  base:  It  includes  description  of  the  meanings  of  data  items, 
the  way  in  which  the  data  are  used,  their  sources,  their  physical  characteristics,  and 
other  rules  or  restrictions  on  their  forms  or  uses. 
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c.  Database  administrator  {DBA) 

As  database  systems  come  into  broader  use  and  organizations  gain 
experience  in  the  use  of  such  systems,  the  need  for  controlling  the  shared  data  and 
maintaining  the  integrity  and  security  of  the  database  becomes  obvious.  The  DBA  is 
assigned  the  administrative  responsibilities  that  must  be  centralized  as  a  result  of  data 
integration,  and  the  technical  responsibilities  that  are  specifically  related  to  the 
database  and  use  of  the  database  management  system. 

The  DBA  is  the  primary  liaison  with  the  users  of  the  data  base.  The  DBA 
collects  and  maintains  data  about  the  data  base  and  makes  this  information  available 
to  potential  data  base  users.  The  DBA  also  maintains  specialized  software  tools  needed 
for  data  base  use,  such  as  data  dictionaries,  query  languages,  or  design  aids.  The  DBA 
may  provide  educational  support  for  database  users,  on  any  or  all  database-related 
software.   [Ref.  12:  pp.  15-16] 

C.       RELATIONAL  DBMS 

1.  Background 

Modern  database  management  systems  emerged  from  the  mid-1970s.  These 
systems  have  been  developed  to  overcome  the  restrictions  of  previous  DB  systems  and 
are  characterized  by  interactive  access  capability.  Several  users  can  run  different 
applications  concurrently  on  the  same  data,  and  the  database  system  will  serialize  these 
data  manipulations  appropriately. 

Trends  in  current  data  processing  environments,  such  as  the  shortage  of  data 
processing  professionals  and  the  increasing  backlog  of  applications,  have  motivated  the 
development  of  database  technology.  This  improves  the  productivity  of  data  processing 
professionals  by  simplifying  the  database  calls  in  the  application  programs  they  write. 
In  addition,  it  makes  it  possible  for  non-DP  professionals  to  specify  their  queries  to  an 
interactive  query  program  and  receive  their  answers  on  a  screen  or  printer,  thereby 
avoiding  the  development  of  an  application  program  altogether. 

Relational  database  management  systems  manifest  the  tendency  in  database 
technology  of  providing  easy  access  to  data  for  people  who  are  not  data  processing 
professionals  as  well  as  those  who  are.  Relational  databases  provide  a  very  simple, 
tabular  view  of  data.  Unlike  the  earlier  hierarchical  and  network  organizations, 
relational  databases  derive  relationships  from  the  data  values  rather  than  having 
explicit  pointers  between  records. 
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2.  Relational  terminology 

Some  terminology  used  frequently  in  describing  relational  systems  is  given 

below: 

Relation:  a  two-dimensional  table  of  data;  flat  files  with  rows  and  columns 

Entity:    any    distinguishable    object    that    is    represented    in    the    data    base; 
conceptual  representation  of  the  primitive  objects 

Attribute:  representation  of  properties  of  objects;  columns  of  relation 

Tuple:  rows  of  a  relation 

Domain:  the  collection  of  all  values  that  an  attribute  can  have 

Degree:  the  number  of  data  items  in  the  record  type;  number  of  columns 

Cardinality:  the  number  of  rows  or  tuples  in  a  relation 

Null  value:  special  values  representing  'unknown'  or  'inapplicable' 

Key:  the  attribute  or  attributes  with  values  that  are  unique  within  the  relation 
and  thus  can  be  used  to  identify  the  tuples  of  that  relation 

Relationship:  conceptual  representation  of  an  association  among  entities 

Relational  schema:  a  description  of  the  structure  of  relations  in  a  relational  data 
base 

•      Relational  database:    a  database  that  is  perceived  by  the  user  as  a  collection  of 
time-varying,  normalized  relations 

3.  Relational  representation  of  data 

The  relational  model  has  the  fundamental  advantage  of  conceptual  simplicity 
for  a  diversity  of  users  in  the  application  environment  (casual  user,  programmer,  etc.) 
who  can  communicate  among  themselves  on  the  basis  of  such  a  unified  framework.  A 
model  is  the  result  of  the  abstraction  of  an  event  and  is  presented  by  a  set  of  entities 
and  relationships.  During  the  process,  relevant  attributes  of  both  objects  and 
relationships  are  chosen  and  classified  into  various  object  types. 

Data  in  the  relational  model  are  represented  by  a  relation  viewed  as  a  table. 
The  table's  heading  defmes  the  relation's  name,  and  each  row  corresponds  to  an  n- 
tuple  of  data  values  describing  a  single  entity.  Also,  data  in  each  column  are  assumed 
to  arise  from  the  same  domain.  A  value  of  a  given  attribute  may  change  over  time,  but 
it  always  belongs  to  the  domain  of  that  attribute. 

An  example  of  the  representation  of  a  student  entity  type  by  a  set  of  tuples 
and  attributes  is  shown  in  Figure  4.1. 
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NAME 

CUR. 

SERVICE 

SMC 

Alice 

Lee 

John 

Kim 

Mary 

827 

815 
837 
817 
817 

USN 

USA 

USN 

ROKA 

USAF 

1425 
1030 
2123 
2362 
2551 

Figure  4.1    A  STUDENT  Relation. 

STUDENT  =  (NAME  *  CUR.  *  SERVICE  *  SMC)  which  represents  that 
each  student  determines  a  unique  tuple.  Each  entity  can  also  be  shown  in  Figure  4.2. 


Entity 


Attributes 


Dormain 


Student  Mail 
Code  Numbers 


Finite  sequenqe 
of  letters (nan 


) 


Curricular 
Numbers 


Finite  sequence 


f  le  tters  ( serT. 


ice ) 


Finite  sequence 
cf  letters (rank ) 


Figure  4.2    Representation  of  STUDENT  entity. 

4.  Relational  algebra 

As  the  expression  'algebra'  implies,  relational  algebra  is  a  way  of  manipulating 
relations  by  using  a  set  of  operators,  such  as  select,  join,  projection  along  with  others. 
Each  operation  of  the  relational  algebra  takes  one  or  more  relation(s)  as  its  operand(s) 
and  produces  a  new  relation  as  the  desired  output. 
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Each  operation  of  the  relational  algebra  takes  one  or  more  relation(s)  as  its  operand(s) 
and  produces  a  new  relation  as  the  desired  output. 

The  operations  are  chosen  in  such  a  way  that  all  well-known  types  of  queries 
may  be  expressed  by  their  composition  in  a  rather  straightforward  way.  The  relational 
algebra  includes  union,  intersection,  difference,  projection,  restriction,  join,  and 
division.   [Ref  14:  p.  24] 

The  first  four  algebra  operations  are  similar  to  high  school  algebra,  and  we 
can  call  them  the  usual  set  operations,  we  will  define  and  illustrate  the  other 
operations  of  relational  algebra  by  using  the  STUDENT  relation  of  the  previous 
section. 

a.   Projection 

Projection  is  an  operation  that  selects  specified  attributes  from  a  relation. 
Given  a  relation  STUDENT,  the  projection    STUDENT  (NAME,  CUR.) 
represents  each  student's  curriculum,  as  shown  in  Figure  4.3. 


NAME 

Cur. 

Alice 

Lee 

John 

Kim 

Mary 

827 
815 
837 
817 
817 

Figure  4.3     Projection. 

b.  Restriction  {or  selection) 

The  restriction  operator  takes  a  horizontal  subset  and  selects  tuples  to  be 
included  in  a  new  relation.  The  restriction  is  defined  by  a  logical  condition  with  a 
rather  simple  expression. 

Given  a  relation  STUDENT,  student  (Cur.  =  817)  represents  the  table  of 
students  who  are  in  'curriculum  817': 

c.  Join 

The  join  operation  is  a  combination  of  the  product,  restriction,  and 
projection  operations.  We  create  another  relation  SERVICE  as  represented  in  Figure 
4.5. 
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NAME 

CUR. 

SERVICE 

SMC 

Kim 
Mary 

817 
817 

ROKA 
.  USAF 

2362 
2551 

Figure  4.4    Restriction. 


NAME 

SERVICE 

RANK 

CUR. 

Smith 
Ryan 
Robert 
Kim 

USN 
USN 
USA 
ROKA 

LT 

LCPT 
MAJ 
CPT 

837 
827 
817 
817 

Figure  4.5    A  SERVICE  Relation. 

Given  relations  of  STUDENT  (Name,  Cur.,  Service,  Rank,  SMC)  and 
SERVICE  (Name,  Service,  Rank,  Cur.),  STUDENT(Service  =  Service) 
SERVICE(Name,  Service,  Cur.)  represents  the  composition  of  two  operations:  the  join 
of  the  relations  STUDENT  and  SERVICE  via  the  attribute  Service,  and  the  projection 
of  the  result  of  the  join  operation  on  the  attributes  Name,  Service,  and  Cur.. 

The  result  of  the  join  operation  is  shown  in  Figure  4.6. 


NAME 

SERVICE 

CUR. 

Alice 

USA 

815 

Robert 

USA 

817 

Lee 

USN 

815 

John 

USN 

837 

Smith 

USN 

837 

Ryan 

USN 

827 

Kim 

ROKA 

817 

Figure  4.6    Join. 

5.  Relational  Query  Language 

The  relational  algebra,  as  a  basic  means  of  retrieval  of  data,  is  not  suitable  as 
a  practical  query  language  for  casual  users  of  the  database  because  it  is  too  procedural. 
A  number  of  relational  query  languages  have  been  developed  which  are  much  simpler 
than  the  relational  algebra  in  posing  queries. 
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Among  the  query  languages,  SQL  (structured  query  language,  formerly 
SEQUEL),  developed  by  IBM,  is  regarded  as  the  most  convenient  and  powerful.  We 
will  use  SQL  as  the  query  language  in  all  subsequent  discussions.  SQL  is  not  just  a 
query  language,  but  it  permits  specification  of  other  actions  on  the  database,  including 
commands  for  data  definition,  data  manipulation  and  data  control  [Ref.  13:  p.  265] 
SQL  commands  can  also  be  embedded  in  application  programs. 

The  basic  form  of  SQL  is: 

SELECT  <list  of  attributes  > 
FROM     <  list  of  relations  > 
WHERE    <  qualification  expression  > 

The  first  two  clauses  (SELECT,  FROM)  in  the  query  block  define  the 
operation  of  projection.  The  qualification  expression  in  the  WHERE  clause  is  a  logical 
expression.  It  contains  attributes  of  relations  listed  in  the  FROM  clause  and 
determines  what  tuples  of  those  relations  qualify  for  the  operation  of  projection.  This 
type  of  nonprocedural  database  language  eliminates  the  need  to  specify  access  paths  to 
the  data. 

The  result  of  execution  of  a  query  block  is  a  relation.  Query  blocks  may 
appear  as  operands  of  the  set  operations.  SQL  operations  are  enumerated  as  in  the 
Table  5. 


TABLE  5 
EXECUTION  OF  QUERY  BLOCK 


Projection 

Restriction  (selection) 

Join 

Union/difference 

Intersection 

Division 

Insertion/Deletion 

Update 
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We  will  present  a  number  of  SQL  examples  using  the  following  schema: 
STUDENT  (Name,    Cur.,    Smc#) 

COURSE  (Coursett,   Hour,   Class  room) 

SERVICE  (Name,   Service,   Rank) 

PROFESSOR       (Professor,   Department,   Course#) 

a.  Projection 

To  obtain  a  list  of  students  and  their  curricula: 
SELECT  Name,    Cur. 

FROM  STUDENT 

b.  Restriction  {selection) 

To  select  all  student  whose  curriculum  is  '817': 
SELECT  * 

FROM  STUDENT 

WHERE  Cur.    =  817 

*  denotes  selection  of  all  attributes  (columns)  of  the  table  STUDENT. 

To  select  a  table  of  STUDENTS  who  have  the  rank  Major  or  LCDR: 

SELECT  * 

FROM  SERVICE 

WHERE  Rank  =  Major 

OR  Rank  =  LCDR 

To  display  the  class  hours  of  course#  taught  by  Professor  A: 
SELECT       Hour 


FROM 

COURSE 

WHERE 

Coursett 

IN 

SELECT 
FROM 

Course# 
PROFESSOR 

WHERE 

Professor  = 

A 

This  example  shows  how  embedding  a  query  from  one  relation  into  a  query 
of  another  permits  implicit  specification  of  the  natural  join  operation. 

c.  Join 

This  query  constructs  a  table  of  student's  names,  curriculum,  service,  and 
ranks.  As  a  rather  simpler  case,  this  query  block  is  a  composition  of  two  operations  of 
relational  algebra:  projection  and  join. 

SELECT         Name,    Cur.,    Service,   Rank 
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FROM      STUDENT,  SERVICE 

WHERE     STUDENT  Name  =  SERVICE  Name 

d.   Other  operations 

The  ability  of  SQL  query  specification  ranges  far  beyond  the  preceding 
examples.  The  other  operations  shown  in  Table  5  can  also  be  constructed  variations  of 
the  examples.  Throughout  the  SQL  manipulation,  considering  the  required  output 
relation,  the  number  and  domain  of  the  attributes  should  be  well  defined  to  facilitate 
the  future  operation. 

D.      SUMMARY 

This  chapter  provided  a  conceptual  overview  of  database  management  systems 
and  relational  data  management  technology.  Since  the  availability  of  timely  and 
accurate  data  is  the  key  in  any  organizational  activity,  demand  for  a  well-developed 
database  is  very  high.  The  data  management  philosophy  gives  a  rationale  for  database 
systems. 

A  database  system,  as  a  mechanized  and  controlled  data  pool,  provides  many 
advantages  that  are  not  available  in  previous  file  systems:  reduced  redundancy;  easy 
application;  program-to-data  independence;  ad  hoc  query;  integrity;  security. 

A  database  management  system  (DBMS)  is  a  set  of  software  making  the  physical 
storage  of  data  operational.  A  data  dictionary/directory  system,  query  languages,  and 
database  administration  (DBA)  are  the  major  elements  of  the  system. 

The  relational  database  model  is  the  most  popular  database  technology  in  use 
today.  Its  flexible  and  powerful  capabilities  enable  ordinary  users  to  perform  many 
queries  using  the  relational  query  language.  Some  basic  examples  of  SQL  operations 
were  introduced  to  illustrate  relational  concepts.  In  the  next  chapter,  we  will  apply 
relational  database  technology  to  the  resource  management  system. 
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V.  DATABASE  APPLICATION  CAPABILITY 

Based  on  the  information  requirements  for  resource  management  identified  in 
Chapter  III,  we  will  show  a  basic  application  of  relational  database  technology.  First 
we  develop  a  logical  design  for  the  defense  resource  management  environment,  then 
derive  the  relations  to  be  processed  in  the  relational  database,  and  finally  illustrate  the 
data  manipulation  required  to  generate  an  output  (creation  of  new  relation).  We  use 
the  SQL  data  manipulation  language  introduced  in  the  previous  chapter. 

A.       APPLICATION  ENVIRONMENT 

1.  Conceptual  Issues 

A  relational  database  is  a  set  of  relations  (tables)  whose  structure  is  specified 
in  the  schema.  The  actual  sets  of  tuples  change  over  time  due  to  various  actions  which 
are  activated  by  the  users  in  the  application  environment  to  reflect  the  changes  that 
happen  over  time  in  that  environment.  However,  only  those  changes  (updates)  of  the 
relational  database  are  accepted  which  perform  in  accordance  with  the  integrity 
constraints.  Users  satisfy  their  information  needs  either  by  triggering  prespecified 
transactions  which  represent  composite  queries  and  produce  appropriate  reports,  or  by 
stating  ad  hoc  queries  using  user-friendly  relational  query  languages. 

The  activities  in  resource  management  are  very  complex  and  multi-faceted. 
The  information  required  to  make  a  sound  decision  for  the  optimal  allocation  of 
resources  and  to  produce  various  analysis  for  future  budgeting  must  be  selected 
carefully  through  systematic  data  processing  procedures.  This  implies  two  principal 
aspects  of  the  data  base  design: 

(a)  Which  data  should  be  collected  and  maintained  in  the  database? 

(b)  How  can  the  required  information  be  generated  by  users? 

Since  we  are  dealing  with  the  relational  database  model,  the  system  should  be 
developed  to  meet  user's  needs  from  the  initial  stage  of  relational  design  in  order  to 
maximize  its  flexibility  for  answering  various  queries.  The  designer  must  also  establish 
priorities  and  make  the  best  possible  compromise  in  light  of  conflicting  factors  such  as 
elimination  of  anomalies,  relation  independence,  and  ease  of  use  [Ref.  13:  pp.307-311]. 
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2.  Prerequisite  of  relational  database  development 

In  order  to  develop  the  resource  database  system,  there  are  some  prerequisites: 

•  Establish  a  coding  system 

•  Establish  a  standard  price  system 

•  Define  a  measurement  units  for  the  different  classes  of  resources 

•  Design  a  reporting  document  format 

A  coding  system  is  a  crucial  factor  for  data  base  processing  and  requires  a 
considerable  effort.  All  input  data  are  recorded  by  using  predefined  codes,  and  the 
codes  should  encompass  all  resource  activities  throughout  the  division.  Coding  systems 
help  to  substantially  reduce  the  amount  of  data  to  be  stored.  We  use  a  preliminary 
coding  system  as  shown  in  Appendix  B. 

The  standard  price  for  each  equipment/ material  is  used  to  convert  the  amount 
transacted  or  resources  expended  into  a  money  value  primarily  for  the  purpose  of 
accounting.  Identical  price  levels  for  an  item  contribute  to  consistent  management  of 
performance  analysis  and  cost-effectiveness  control  of  the  unit. 

Since  the  division  has  so  many  kinds  of  resources  with  different  units  of 
measurement,  it  would  be  very  confusing  and  impractical  to  record  the  measurement 
unit  every  time  in  the  relation.  So  we  need  to  decide  a  basic  unit  for  each  input  data 
element,  which  can  be  configured  automatically  according  to  the  resource  code. 

As  defined  in  Chapter  II,  the  single  format  of  the  current  report,  called  the 
Resource  Transaction  Slip,  causes  deficiencies  in  generating  some  operational  data.  The 
new  report  format  should  be  designed  to  overcome  this  problem.  It  is  recommended 
that  the  report  prepared  by  the  subordinate  unit  include  all  the  required  data  items  to 
meet  the  diverse  information  requirements  and  to  exploit  the  advantage  of  relational 
DBMS.  Considering  the  multifaceted  resource  activities  and  database  input  format,  the 
redesigned  report  should  be  developed  separately  for  each  resource  class  and  activity 
rather  than  as  a  single  uniform  report. 

B.       LOGICAL  MODEL  OF  THE  DRMS 

Designing  the  DBMS  for  DRMS  is  divided  into  two  phases:  logical  and  physical 
design.  Before  getting  into  the  specific  matters  of  database  design,  the  designer  needs  to 
review  the  environment  of  the  system  and  the  user's  information  requirements. 
Through  a  series  of  abstraction  processes,  the  designer  can  identify  the  relationships  of 
the  individual  data  to  be  stored.  This  process  is  called  a  logical  design.  Then,  based  on 
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the  result,  the  designer  builds  a  physical  design,  where  the  logical  design  is  developed 
into  the  constraints  of  particular  program  and  hardware  products. 

We  first  provide  the  outline  of  data  flows  along  the  major  activities  within  the 
DRMS  system,  as  in  Figure  5.1.  Since  a  logical  database  design  is  a  representation  of 
reality,  it  will  be  helpful  to  understand  the  system,  and  further  to  plot  the  logical 
model. 


CASH  /  BUDGET  TR 


MATERIAL  SUPPLIES  TR 


EXPENDITURE 


MAINTENANCE 


budget  allocation    budget  allocation 


cash  receiv 


return 


request 


y~s 


cash   receiv 


return 


request 


/ 


LSC      receive  /  nrvTSTn*  receive 


return 


return 


inTUTOTnM\Exp.  reporf  ORG.   \ Exp. report 

[DIVISION  | ■■ ■—*(    UNITS 


inventory  repopt^^^cinventory  repo 


request 


Figure  5.1     Activity  Chart  of  DRMS. 
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Next,  we  analyze  in  more  detail  the  phenomena  of  the  system,  focusing  on  the 
user's  information  requirements  described  in  Chapter  3.  Throughout  the  analysis,  we 
try  to  answer  the  questions  like  :  1)  what  are  the  prominent  objects  (entities)  of  the 
system?;  2)  what  aspects  of  reality  are  we  trying  to  represent?;  3)  what  are  the 
relationships  between  the  entities?  By  answering  these  questions  we  can  formulate  a 
logical  model  of  the  DRMS  as  shown  in  Figure  5.2.  This  logical  model  provides  the 
conceptual  foundation  for  the  following  relational  representation. 


Figure  5.2     Logical  model  of  DRMS. 
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Entities  of  the  resource  management  system  are  represented  as  squares  and 
relationships  shown  by  circles  are  named  transaction,  expenditures,  operations,  and 
inventory  respectively  in  the  DRMS.  A  relationship  may  exist  between  just  two  entities 
or  among  more  entities  depending  on  the  activities  involved.  For  example  in  the  case  of 
the  EXPENDITURE  relation,  the  expenditure  activities  are  established  when  a  unit 
uses  any  resources  for  certain  operational  purposes. 

C.       FORMATION  OF  A  RELATION 

A  relation  can  be  viewed  conceptually  as  a  two-dimensional  table  that  has  several 
properties.  Based  on  the  logical  model  previously  defined,  each  object  (entity)  or 
relationship  forms  a  relation,  except  some  objects  with  a  single  value  (attribute),  which 
are  is  regarded  as  the  unique  characteristics  in  the  military  situation. 

Now,  before  representing  those  relations,  in  which  all  the  resource  activities  are 
recorded  and  stored  as  input  data  for  the  purpose  of  future  analysis,  fust  let  us  explain 
some  common  attributes  of  relations. 

1.  Attributes  of  relations 

A  relation  is  a  table  which  can  be  processed  within  the  relational  database 
system.  When  a  resource  is  transacted  or  expended  by  the  unit(s),  this  event  should  be 
recorded  in  the  appropriate  relations. 

The  issue  then  becomes  what  kind  of  data  to  include  as  attributes  and  how  to 
record  them?  These  considerations  are  closely  associated  with  the  desired  output 
information. 

Generally,  each  relation  associated  with  resource  activities  should  have  the 
following  attributes  (contents): 

•  Transaction  number  (TR#):  a  serial  number  given  to  each  transaction  activity 
according  to  its  time  sequential  occurance. 

•  Time:  time  period  or  date  when  the  resource  activities  happen 

•  Unit:  the  unit  (division,  regiment,  etc.)  which  assumes  the  responsible 
accounting  entity.  In  the  case  of  transaction,  units  are  divided  into  supplier  and 
recipient. 

•  Resource:  the  identified  material  that  is  transacted  or  expended.  iMaterials  are 
sub-classified  into  individual  items  within  the  seven  asset  groups. 

•  Stock#:  All  the  government  supplied  items  are  given  numbers  according  to  the 
class  and  characteristics. 

•  Purpose:  Every  expenditure  is  classified  as  ordinary  maintenance;  command  and 
staff  activities;  major  mission  accomplishment;  troop  welfare;  investment; 
training  and  exercises,  etc.. 
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•  Amount:  the  number  or  volume  transacted  or  expended  resources.  Since  the 
different  materials  have  different  units  of  measurement,  we  need  to  decide  a 
uniform  rule  for  the  basic  unit  of  each  resource-related  input  data,  such  as  S, 
kg,  gallon,  unit,  round,  etc.. 

•  Svalue:  the  money  value  of  the  resources  transacted  or  expended.  By 
introducing  a  standard  price  system,  the  whole  Army  (defense  system)  can  apply 
identical  price  levels  for  each  resource  item.  This  is  very  convenient  and  helpful 
in  maintaining  consistent  performance  measurement  and  cost-effectiveness 
control  of  the  unit. 

2.  Representation  of  Relation 

An  Army  division  has  seven  classes  of  floating  assets  by  and  large:  (1)  cash, 
(2)  food,  (3)  petroleum,  (4)  ammunitions,  (5)  repair  parts,  (6)  individual  maintenance 
material,  (7)  troop  maintenance  material.  Most  of  the  resource  management  activities 
originate  from  the  transaction  and  expenditures  on  those  resources.  Data  collection  of 
equipment  operations  and  the  determination  of  inventory  level  are  also  important 
aspects  of  the  DRMS.  To  cover  all  activities  of  the  Army  division,  many  different 
relations  will  be  designed  to  form  a  single  data  pool  in  the  relational  database.  One  of 
the  most  important  considerations  in  designing  the  relations  is  the  elimination  of 
anomalies  (insertion,  deletion,  update).  The  attributes  comprising  the  key  of  each 
relation  are  displayed  in  capital  letters. 
a.   Common  Entity  data 

Resource,  unit  (supplier,  recipient,  expenditure  unit),  and  equipment  are  the 
entities  applied  to  every  relation.  Units  and  equipment,  however,  have  only  a  single 
attribute  and  can  be  identified  by  unique  code  numbers  (refer  to  Appendix  A). 

Resources  can  be  classified  into  two  groups  according  to  their  usage 
characteristics:  budget/cash,  supplies  material  (weight  material).  So  they  are 
represented  in  different  relations  like  Figures  5.3  and  5.4. 

(1)    Budget  relation. 


BUDGET# 

Exp.  item# 

Amount 

Figure  5.3    BUDGET  relation. 
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RESOURCE# 

Stock# 

Price 

Figure  5.4    RESOURCE  relation. 

b.    Transaction  Data 

The  transaction  activities  are  divided  into  three  parts  according  to  their 
characteristics:  (a)  supplies  request,  (b)  cash/budget  transactions,  (c)  supplies 
( material/ equipment)  transactions. 

(1)  Request  relation.  The  REQUEST  relation  consists  of  five  attributes 
(request  number,  time,  resource  code,  requested/canceled  amount)  as  shown  in  Figure 
5.5. 


REQUEST# 

Time 

Resource# 

Amount 

Figure  5.5    SUPPLIES-REQUEST  relation. 

(2)  Cash/budget  transaction.  Transaction  data  should  be  recorded  for  each 
occurrence  of  budget  allocation  and  receipt/ transfer  of  cash.  The  format  for  the 
CASH-TRANSACTION  relation  is  shown  in  Figure  5.6. 


TR# 

Time 

Issuer 

Recipient 

Budge t# 

Amount ($) 

Figure  5.6    CASH-TRANSACTION  relation. 

The  attribute  TR#'  (transaction  code)  identifies  three  cases  of 
transaction  and  is  numbered  in  a  time  sequential  manner.  'Issuer'  indicates  the  higher 
level  of  unit  (Corps,  Army  command)  in  the  case  of  budget  allocation  or  transfer  of 
cash,  while  'recipient'  stands  for  the  subordinate  organizational  unit  or  functional  staff 
office  when  there  is  a  transfer  of  cash.    'Budget  code'  is  for  the  detailed  budget  item 
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from  the  chapter  through  subitems.  'Expense  item  code'  assigns  the  specific  item  where 
the  budget/cash  should  be  expended.  The  detailed  contents  of  the  attribute  are 
explained  in  Appendix  A  (coding  system). 

(3)  Supplies  Transaction.  Supplies  transactions  deal  with  the  weight 
material,  namely  all  the  floating  assets  except  cash.  The  relation  shows  all  the  supplies 
flow  activities,  such  as  receipt,  issues,  and  return.  As  shown  in  Figure  5.7,  the 
transaction  of  the  weight  material  which  moves  in  and  out  of  the  division  can  be 
represented  with  six  attributes. 


TR# 

Time 

Supplier 

Recipient 

Resource# 

Amount 

Figure  5.7    SUPPLIES-FLOW  relation. 

c.   Expenditure  Data 

Detailed  data  about  resource  expenditures  are  very  informative  in  revealing 
what  kind  of  and  how  much  resources  are  used  for  what  purpose.  Since  the  lower  level 
of  units,  such  as  company,  are  the  major  source  of  the  actual  data,  the  division  plays 
the  most  important  role  in  collecting  the  various  operating  data  efficiently  and  in 
generating  reports  or  desired  analyses. 

In  the  previous  chapter,  we  classified  the  resources  into  seven  floating 
assets.  They  have  different  usage  and  characteristics,  so  it  is  rational  to  store  the  data 
separately  in  three  different  relations:  cash,  weight  material,  and  repair  parts. 

(1)  Cash  expenditure  Relation.  This  relation  includes  all  the  resource 
activities  supported  by  the  cash. 


BUDGET# 

Unit 

Time 

Purpose 

Facility 

Equipment 

Amount 

Figure  5.8    CASH-EXP  relation. 
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An  organizational  unit  or  staff  office  records  the  related  data  when  the 
cash  is  paid  to  the  subordinate  unit  or  the  contractor.  The  attribute  'facility'  or 
'equipment'  is  applicable  when  the  cash  is  used  to  maintain  or  repair  either  object. 

(2)  Material  expenditure  relation.  This  relation  records  expenditure 
activities  of  weight  material  without  repair  parts,  namely  five  resource  classes' 
expenditure.  A  new  tuple  is  added  periodically  or  at  the  time  of  a  major  event  by 
summing  the  amount  of  consumption  for  each  unit. 


RESOURCES 

UNIT 

TIME 

PURPOSE 

EQUIPMENT 

Facility 

Amount 

Figure  5.9    iMATERIAL-EXP  relation. 

(3)  Repair  parts  Relation.  Considering  the  unique  characteristics  of  the 
maintenance  activity  (refer  to  Figure  5.1),  the  REPAIR- PARTS  relation,  although 
similar  to  MATERIAL-EXP,  is  prepared  separately.  For  every  occurrence  of  a 
maintenance  job,  the  unit  adds  a  new  tuple  to  the  relation  in  Figure  5.10  .  Based  on  the 
cumulative  records  of  repaired  or  exchanged  parts  of  the  equipment,  the  unit  can 
determine  the  average  life  (cost)  of  the  equipment. 


RESOURCES 

Unit 

TIME 

Recipient 

EQUIPMENT 

Purpose 

E/M 

Amount 

Figure  5.10    REPAIR- PARTS  relation. 

d.   Operational  data 

The  other  relations  are  mainly  oriented  to  the  transaction  and  expenditure 
activities.  Data  about  the  operational  performance  and  the  current  status  of  the 
available  resources  must  also  be  included.  The  OPERATIONS  and  INVENTORY 
relations  are  designed  to  account  for  these  defaulted  data. 

(1)  Equipment  operation  relation.  The  operational  performance  data  are 
needed  to  generate  useful  information  about  expense  coefficients  and  performance 
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analysis.  The  attribute  'operation'  holds  the  operational  performance  result  of  the 
equipment  for  a  certain  period.  An  example  of  input  data  is  as  follows:  1000  miles 
(maneuvering  equipment);  500  hours  (generator). 


EQUIPMENT 

Unit 

TIME 

PURPOSE 

Operation 

Figure  5. 1 1     OPERATIONS  relation. 

In  some  cases,  the  operational  data  can  be  obtained  from  the  relations 
of  other  functional  departments  within  the  relational  database  system. 

(2)  Inventory  check-up  relation.  While  the  division  maintains  the  data  of 
transaction/expenditure  activities,  periodic  check-up  is  recommended  to  prevent  the 
erroneous  estimation  of  the  stock  level.  Coupled  with  the  transaction  and  the  separate 
expenditure  relation,  an  inventory  check-up  relation,  as  in  Figure  5.12,  keeps  track  of 
the  exact  amount  of  resource  available  to  the  unit  at  a  specific  point  of  time. 


RESOURCE 

UNIT 

TIME 

Amount 

Figure  5.12    INVENTORY-CHECK-UP  relation. 

Each  organizational  unit  of  the  division  is  required  to  review  its  stock 
level  periodically  (quarterly  or  annually),  and  the  data  in  the  relation  represents  the  on 
hand  stock  level  at  the  time  of  physical  counting. 

D.      SQL  MANIPULATION 

Data  stored  in  a  database  are  valuable  only  when  they  are  retrieved  to  meet  the 
user's  information  requirements  through  the  data  manipulation  process.  SQL  is  well 
known  as  a  powerful  and  flexible  data  manipulation  language  and  is  becoming  a 
standard  for  relational  DBMS.  Now  we  illustrate  a  set  of  SQL  operations  for  three 
examples  using  simulated  data  for  the  purpose  of  illustration. 
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1.  Case  I:  Information  for  Expense  Coefficient 

The  expense  coefficient  is  used  as  the  basis  for  estimating  the  standard  cost  in 
operating  a  piece  of  equipment.  To  produce  a  reliable  expense  coefficient,  the 
regression  method  is  commonly  used.  The  required  information  includes  any  data 
influencing  the  total  expense  which  can  subsequently  be  used  as  possible  variables  of 
the  regression  equation. 

Here  we  take  the  example  of  a  1/4  ton  jeep,  as  typical  equipment  applicable  to 
all  units.  The  first  thing  to  do  is  to  get  the  resource  expenditure  data  and  the 
operational  data  for  certain  operational  conditions.  We  show  the  data  manipulation 
via  an  actual  SQL  operation,  given  the  data  in  Figure  5.13,  Figure  5.14,  Figure  5.15, 
and  Figure  5.16. 


Resource** 

Unit 

Time 

Purpose 

Equipment 

Facility 

Amount 

1503 

3100 

870115 

31 

11010300 

48,000 

1503 

3300 

870115 

31 

11010300 

51,600 

1510 

4200 

870115 

31 

13010520 

76 

3301 

3100 

870115 

10 

31012010 

300 

3301 

3100 

870115 

20 

31012010 

610 

3301 

3100 

870115 

31 

31012010 

425 

3301 

3200 

870115 

10 

31012020 

240 

3301 

3200 

870115 

20 

31012020 

630 

3301 

3300 

870115 

10 

31012030 

230 

3301 

3300 

870115 

20 

31012030 

400 

3301 

3300 

870115 

31 

31012030 

280 

3301 

4100 

870115 

10 

31012040 

410 

3301 

4100 

870115 

20 

31012040 

950 

3301 

4200 

870115 

10 

31012050 

360 

3301 

4200 

870115 

20 

31012050 

475 

3301 

4200 

870115 

31 

31012050 

310 

3302 

4200 

870115 

31 

31050520 

430 

1503 

3200 

870130 

31 

11010300 

49,200 

1503 

4100 

870130 

31 

11011300 

32,000 

1510 

4100 

870130 

31 

13010510 

72 

3301 

3100 

870130 

10 

31012010 

350 

3301 

3100 

870130 

20 

31012010 

470 

3301 

3200 

870130 

10 

31012020 

260 

3301 

3200 

870130 

20 

31012020 

575 

3301 

3200 

870130 

31 

31012020 

450 

3301 

3300 

870130 

10 

31012030 

195 

3301 

3300 

870130 

20 

31012030 

420 

3301 

4100 

870130 

10 

31012040 

470 

3301 

4100 

870130 

20 

31012040 

1,110 

3301 

4100 

870130 

31 

31012040 

360 

3301 

4200 

870130 

10 

31012050 

390 

3301 

4200 

870130 

20 

31012050 

680 

3302 

4100 

870130 

31 

31050510 

520 

Figure  5.13     MATERIA L-EXP  relation. 
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Resourced 

Unit 

Time 

Recipient 

Equipment 

Purpose 

E/M 

Amount 

1411 

3100 

870115 

3110 

11010300 

31 

3 

3412 

3100 

870115 

3110 

31012010 

10 

2 

3415 

6100 

870115 

3200 

31012020 

10 

II 

1 

3416 

3200 

870115 

3230 

31012020 

20 

1 

3417 

4100 

870115 

4110 

31012040 

10 

2 

3419 

4200 

870115 

4220 

32012050 

10 

5 

3451 

6100 

870115 

4200 

31050520 

31 

II 

3 

1411 

3200 

870130 

3230 

11010300 

31 

5 

1458 

0300 

870130 

4100 

13010510 

31 

III 

1 

3411 

3100 

870130 

3120 

31012010 

20 

2 

3412 

3200 

870130 

3210 

31012020 

31 

2 

3415 

3300 

870130 

3330 

31012030 

20 

2 

3415 

4100 

870130 

4120 

31012040 

20 

2 

3417 

4100 

870130 

4130 

31012040 

31 

3 

3417 

4200 

871030 

4210 

31012050 

20 

1 

3459 

6100 

870130 

4100 

31050510 

31 

II 

2 

Figure  5.14     REPAIR-PARTS  relation. 


Equipment 

Unit 

Time 

Purpose 

Operation 

31012010 

3100 

870115 

10 

560 

31012010 

3100 

870115 

20 

1,300 

31012010 

3100 

870115 

31 

500 

31012020 

3200 

870115 

10 

310 

31102020 

3200 

870115 

20 

1,900 

31012030 

3300 

870115 

10 

210 

31012030 

3300 

870115 

20 

850 

31012030 

3300 

870115 

31 

300 

31012040 

4100 

870115 

10 

1,000 

31012040 

4100 

870115 

20 

2,700 

31012050 

4200 

870115 

10 

700 

31012050 

4200 

870115 

20 

1,500 

31012050 

4200 

870115 

31 

700 

31050520 

4200 

870115 

31 

450 

31012010 

3100 

870130 

10 

440 

31012010 

3100 

870130 

20 

1,700 

31012020 

3200 

870130 

10 

440 

31012020 

3200 

870130 

20 

1,600 

31012020 

3200 

870130 

31 

500 

31012030 

3300 

870130 

10 

290 

31012030 

3300 

870130 

20 

1,150 

31012040 

4100 

870130 

10 

1,200 

31012040 

4100 

870130 

20 

2,500 

31012040 

4100 

870130 

31 

600 

31012050 

4200 

870130 

10 

500 

31012050 

4200 

870130 

20 

1,300 

31050510 

4100 

870130 

31 

480 

Figure  5.15    OPERATIONS  relation. 
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Resource# 

Stock* 

Price 

1411 

1-23-15 

10,000 

1458 

1-23-56 

220,000 

3301 

3-20-05 

3,000 

3411 

3-23-11 

75,000 

3412 

3-23-21 

100,000 

3415 

3-23-52 

115,000 

3416 

3-23-64 

75,000 

3417 

3-23-71 

37,000 

3419 

3-23-93 

70,000 

3451 

3-34-86 

150,000 

3459 

3-34-92 

123,000 

Figure  5.16    RESOURCE  relation. 

In  order  to  produce  a  table  of  data  resource  expenditures  on  1/4  ton  jeeps  for 
different  operational  conditions,  an  SQL  query  block  must  be  designed.  This  example 
requires  a.  typically  simple  query  operation  with  SELECT,  FROM,  and  WHERE 
working  on  4  relations.  Basically  this  query  block  is  a  composition  of  the  relational 
algebra  operations  of  projection  and  join  under  one  restriction.  In  other  words, 
relations  MATERIAL-EXP  and  OPERATIONS  are  joined  by  attributes  Equipment, 
Purpose,  Time,  and  Unit  whereas  relations  MATERIAL-EXP  and  RESOURCE  are 
joined  by  attribute  Resource#.  A  RESOURCE  relation  is  provided  to  produce  a  unit 
money  value  for  each  resource  expended. 

Given  the  relations  described  above,  we  formulate  two  separate  query  blocks 
to  facilitate  the  query  operation.  Now  we  illustrate  each  procedure  step  by  step  to 
reach  the  final  information. 

The  first  query  block  represents  the  projection  and  join  operation  over  the 
MATERIAL-EXP  and  OPERATIONS  relations  as  follows: 

SELECT       MATERIAL-EXP.  Equipment,  MATERIAL-EXP.  Resource#, 
MATERIAL-EXP.  Purpose,  SUM(Operation),  SUM(Amount), 

FROM  MATERIAL-EXP,  OPERATIONS 

WHERE        MATERIAL-EXP.  Equipment   IN  (31012010,  31012020,  31012030, 
31012040,31012050) 
AND  MATERIAL-EXP.  Equipment  =  OPERATIONS.  Equipment 

AND  MATERIAL-EXP.  Purpose  =  OPERATIONS.  Purpose 

AND  MATERIAL-EXP.  Time  =  OPERATIONS.  Time 

AND  MATERIAL-EXP.  Unit  =  OPERATIONS.  Unit 
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GROUP  BY  Equipment,  Purpose,  Time 

ORDER  BY  Equipment 

The  relation,  as  in  Figure  5.17,  resulting  from  the  query  shows  the  amount  of 
resource  (3301;  gasoline)  used  for  equipment  operations  (maneuvering  mileage)  and 
three  operational  purposes. 


Equipment 

Resource 

i  Purpose 

Operatior 

Amount 

31012010 

3301 

10 

1,000 

650 

31012010 

3301 

20 

3,000 

1,080 

31012010 

3301 

31 

500 

425 

31012020 

3301 

10 

700 

600 

31012020 

3301 

20 

3,500 

1,205 

31012020 

3301 

31 

500 

450 

31012030 

3301 

10 

500 

425 

31012030 

3301 

20 

2,000 

820 

31012030 

3301 

31 

300 

280 

31012040 

3301 

10 

2,200 

890 

31012040 

3301 

20 

5,200 

2,060 

31012040 

3301 

31 

700 

360 

31012050 

3301 

10 

1,200 

750 

31012050 

3301 

20 

2,800 

1,155 

31012050 

3301 

31 

600 

310 

Figure  5.17    MATERIAL  EXPENDITURE  ON  1/4  TON  JEEP. 


The  second  query  block  is  designed  to  produce  data  about  the  amount  and 
Svalue  of  the  repair-parts  expenditures  for  each  operational  purpose,  as  follows: 
SELECT    REPAIR- PARTS.  Equipment,  REPAIR-PARTS.  Resource#, 
REPAIR-PARTS.  Purpose,  SUM(Operation),  SUM(Amount), 
SUM(Amount*Price) 

FROM       REPAIR-PARTS,  OPERATIONS,  RESOURCE 

WHERE      REPAIR-PARTS.  Equipment  IN  (31012010,  31012020,  31012030, 
31012040,31012050) 
AND         REPAIR-PARTS.  Equipment  =  OPERATIONS.  Equipment 
AND         REPAIR-PARTS.  Purpose  =  OPERATIONS.  Purpose 
AND         REPAIR-PARTS.  Time  =  OPERATIONS.  Time 
AND         REPAIR-PARTS.  Unit  =  OPERATIONS.  Unit 
AND         REPAIR-PARTS.  Resource^  =  RESOURCE.  Resource# 

GROUP  BY  Equipment,  Resource,  Purpose 

ORDER  BY  Equipment 
The  output  data  is  generated  as  in  Figure  5.18 
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Equipment 

Resource 

Purpose 

Operatior 

Amount 

$Value 

31012010 

3412 

10 

560 

2 

200,000 

31012010 

3411 

20 

1,700 

2 

150,000 

31012020 

3412 

31 

500 

2 

200,000 

31012020 

3415 

10 

310 

1 

115,000 

31012020 

3416 

20 

1,900 

1 

75,000 

31012030 

3415 

20 

1,150 

2 

230,000 

31012040 

3415 

20 

2,500 

2 

230,000 

31012040 

3417 

10 

1,000 

2 

74,000 

31012040 

3417 

31 

600 

3 

111,000 

31012050 

3417 

20 

700 

1 

37,000 

31012050 

3419 

10 

1,300 

5 

350,000 

Figure  5.18     REPAIR  PARTS  EXPENDITURE  ON  1/4  TON  JEEP. 

Finally,  we  want  to  combine  the  above  two  tables  (Figure  5.17  and  5.18)  to  get  the 
final  information  in  a  single  table  which  explains  all  resource  expenditures  on  the  1/4 
ton  jeep  according  to  operational  purpose  and  performance  with  the  S  value  for  the 
repair  parts. 

In  order  to  do  this,  however,  we  need  to  restructure  the  design  somewhat.  In 
particular,  we  combine  the  two  relations  MATERIAL-EXP  and  REPAIR-PARTS  into 
a  single  base  relation  as  follows: 

PHYSICAL-EXP  (Type,  Resource#,  Equipment,  Time,  Purpose,  Unit,  Amount, 
Facility,  Recipient,  E/M) 

Then  we  can  create  the  tables  MATERIAL-EXP  and  REPAIR-PARTS  as  views  on 
the  general  base  relation  as  follows: 

CREATE  VIEW  MATERIAL-EXP  AS 

(SELECT  Resource#,  Unit,  Time,  Purpose,  Equipment,  Facility,  Amount 
FROM      PHYSICAL-EXP 
WHERE    Type  =  'ME' 

CREATE  VIEW  REPAIR-PARTS  AS 

(SELECT  Resource#,  Unit,  Time,  Recipient,  Equipment,  Purpose,  E/M, 
Amount 
FROM      PHYSICAL  EXP 
WHERE    Type  =  'RP') 
This  allows  us  to  use  the  SQL  commands  exactly  as  above  but  with  the  added 
flexibility  of  generating  the  overall  expenditure  table  by  substituting  PHYSICAL-EXP 
for  MATERIAL-EXP  (or  REPAIR-PARTS).   This  will  yield  the  table  in  Figure  5.19. 
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Equipment 

Resource 

Purpose 

Operatior 

Amount 

Amt*Price 

31012010 

3301 

10 

1,000 

650 

1,950,000 

31012010 

3301 

20 

3,000 

1,080 

3,240,000 

31012010 

3301 

31 

500 

425 

1,275,000 

31012010 

3412 

10 

560 

2 

200,000 

31012010 

3411 

20 

1,700 

2 

150,000 

31012020 

3301 

10 

700 

600 

1,800,000 

31012020 

3301 

20 

3,500 

1,205 

3,615,000 

31012020 

3301 

31 

500 

450 

1,350,000 

31012020 

3412 

31 

500 

2 

200,000 

31012020 

3415 

10 

310 

1 

115,000 

31012020 

3416 

20 

1,900 

1 

75,000 

31012030 

3301 

10 

500 

425 

1,275,000 

31012030 

3301 

20 

2,000 

820 

2,460,000 

31012030 

3301 

31 

300 

280 

840,000 

31012030 

3415 

20 

1,150 

2 

230,000 

31012040 

3301 

10 

2,200 

890 

2,670,000 

31012040 

3301 

20 

5,200 

2,060 

6,180,000 

31012040 

3301 

31 

700 

360 

1,080,000 

31012040 

3415 

20 

2,500 

2 

230,000 

31012040 

3417 

10 

1,000 

2 

74,000 

31012040 

3417 

31 

600 

3 

111,000 

31012050 

3301 

10 

1,200 

750 

2,250,000 

31012050 

3301 

20 

2,800 

1,155 

3,465,000 

31012050 

3301 

31 

600 

310 

930,000 

31012050 

3417 

20 

700 

1 

37,000 

31012050 

3419 

10 

1,300 

5 

350,000 

Figure  5.19    RESOURCE  EXPENDITURE  ON  1/4  TON  JEEP. 

2.  Case  II:  Resource  expenditure  result  of  an  exercise 

Data  about  the  resource  expenditure  of  an  exercise  provides  valuable 
information  for  budget  allocation  and  for  the  estimation  of  minimum  wartime  resource 
requirements.  Relational  database  systems  can  produce  the  required  information  with  a 
simple  query  block. 

SELECT      Resource^  Unit,  SUM( Amount) 

FROM        (Associated)  RELATIONS 

WHERE       Time  =  (a  specific  date  or  period) 
AND        Purpose  =    Exercise  code  number 

By  using  the  same  data  as  in  Case  I,  let  us  perform  an  SQL  manipulation  to 
determine  the  amount  of  resources  expended  in  field  exercise  identified  with  Code  31, 
which  occurred  during  the  second  half  of  January  1987: 

SELECT  Resource#,  Unit,  SUM(Amount) 

FROM  PHYSICAL-EXP 

WHERE  Time  =  870130 

AND  Purpose  =  31 
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GROUP  BY  Resource^  Unit 

ORDER  BY  Resource# 

The  table  resulting  from  this  query  is  shown  in  Figure  5.20.  Note  that  by 
using  the  PHYSICAL-EXP  table  in  the  query,  we  get  both  material  and  repair  parts 
expenditures.  If  we  had  desired  only  material  expenditures,  for  example,  we  could  have 
generated  that  table  simply  by  substituting  MATERIAL-EXP  for  PHYSICAL-EXP  in 
the  above  query. 


Resource# 

Unit 

Amount 

1411 

3200 

5 

1458 

4100 

1 

1503 

3200 

49,200 

1503 

4100 

32,000 

1510 

4100 

72 

3301 

3200 

450 

3301 

4100 

360 

3302 

4100 

520 

3412 

3200 

2 

3417 

4100 

3 

3459 

4100 

2 

Figure  5.20    Resource  Expenditure  in  Field  Exercise. 

We  can  display  this  output  data  in  various  formats,  according  to  the  desired 
usage  of  the  information.  In  some  cases  we  might  need  data  only  about  the  total 
amount  of  resource  expenditure  at  the  division  level,  while  in  other  cases  we  might 
differentiate  the  amount  for  each  organizational  unit.  The  latter  case  is  mainly  used  for 
the  purpose  of  unit  performance  evaluation,  comparing  the  expenditure  amount  with 
its  performance  results  (mission  accomplishment).  The  amount  of  the  resource  can 
also  be  also  converted  into  a  money  value  by  using  the  'price'  attribute  of  RESOURCE 
relation  for  accounting  purposes. 

3.  Case  III:  Determination  of  the  Inventory  level 

The  division  performs  a  physical  counting  of  the  inventory  level  periodically 
and  maintains  its  records  for  each  resource  of  the  unit.  However,  the  current  system, 
without  the  database  facilities,  encounters  many  difficulties  in  determining  the  accurate 
resource  level  available  at  a  certain  point  of  time.  It  relies  upon  many  interrelated 
documents  which  takes  a  considerable  amount  of  time. 
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However,  with  some  simple  relational  database  query  operations,  we  can 
figure  out  the  exact  level  of  on-hand  stock,  easily.  As  shown  in  the  logical  model 
previously  introduced,  the  current  stock  level  is  determined  from  3  sources:  inventory 
check-up,  expenditure  records,  and  transaction  results. 

Now  we  present  an  example  SQL  query  which  provides  the  desired 
information.  For  the  purpose  of  representation,  we  suppose  that  we  want  to  know  the 
ammunition  stock  level  of  the  2nd  Infantry  Regiment  at  the  beginning  of  February 
1987.  In  order  to  make  the  desired  data  manipulation,  we  need  the  SUPPLIES-FLOW 
and  INVENTORY-CHECK-UP  relations  in  addition  to  the  expenditure  data  from  the 
previous  section.  Figure  5.21  and  Figure  5.22  provide  the  sample  data  for  these 
relations. 


TR# 

Time 

Supplier 

Recipient 

Resources 

Amount 

11401 

870105 

0410 

3100 

1505 

10,000 

11402 

870110 

0410 

3200 

1505 

10,000 

11403 

870115 

0410 

3300 

1505 

10,000 

21402 

870116 

3100 

6200 

1505 

20,000 

11405 

870120 

0410 

3200 

1503 

40,000 

11406 

870125 

6200 

4100 

1503 

25,000 

21406 

870129 

3200 

6200 

1503 

10,000 

Figure  5.21     SUPPLIES-FLOW  relation. 


Resource 

Unit 

Time 

Amount 

1503 

3100 

860615 

15,000 

1503 

3200 

860615 

23,000 

1503 

3300 

860615 

18,000 

1503 

4100 

860615 

9,000 

1503 

4200 

860615 

8,600 

1503 

6200 

860615 

50,000 

1503 

3100 

870110 

25,000 

1503 

3200 

870110 

30,000 

1503 

3300 

870110 

21,000 

1503 

4100 

870110 

11,000 

1503 

4200 

870110 

9,000 

1503 

6200 

870110 

60,000 

Figure  5.22    INVENTORY-CHECK-UP  relation. 
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Before  getting  into  the  SQL  operation,  let  us  explain  the  logic  of  the  required 
query  in  the  ordinary  algebraic  terms: 

Current  Inventory  Level  =    {(Previous  Inventory  Level)  +   (Received  Material)}  - 
{(Expended  Material)  +  (Returned  Material)} 

This  information  requires  four  separate  query  blocks  as  follows: 

(1)  Previous  Inventory  Level: 

SELECT  Amount 

FROM      INVENTORY-CHECK-UP 

WHERE    Time  =  870110 

AND      Unit  =  3200 

AND      Resource#  =  1503 

(2)  Received  Material: 

SELECT  SUM(Amount) 

FROM      SUPPLIES-FLOW 

WHERE    Resource#  =  1503 
AND      Recipient  =  3200 
AND     Time  BETWEEN  870110  AND  870131 

(3)  Expended  Material: 

SELECT  SUM(Amount) 
FROM      MATERIAL-EXP 
WHERE    Resource#  =  1503 

AND      Unit  =  3200 

AND     Time  BETWEEN  870110  AND  870131 

(4)  Returned  Material: 

SELECT  SUM( Amount) 
FROM      SUPPLIES-FLOW 
WHERE     Resource#  =  1503 
AND      Supplier  =  3200 
AND     Time  BETWEEN  870110  AND  870131 
From  the  above  queries  we  get  the  resulting  amounts  of  30,000,  40,000, 
10,000,   and  49,200   respectively.    By   using   the   report   generator   capability   of  the 
database  system,  we  can  generate  a  single  value  of  present  stock  level  as  shown  in 
Figure  5.23. 
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Resource# 

Unit 

Amount 

1503 

3200 

10,800 

Figure  5.23    CURRENT  INVENTORY  LEVEL. 

This  kind  of  query  procedure  is  usually  supported  by  the  report  generator 
capability  of  the  database  system.  Apart  from  the  ad  hoc  queries,  some  typical 
information  required  frequently  can  be  generated  easily  with  embedded  query 
procedures. 

E.       DATA  BASE  ADMINISTRATION 

So  far  we  have  discussed  the  application  capabilities  of  a  relational  database 
management  system.  The  database  system  makes  possible  flexible  application  of  the 
shared  data  by  various  queries.  Now  we  need  to  pay  attention  to  another  aspect  of  the 
DRMS:  How  can  we  administer  the  database  effectively  to  satisfy  the  information 
requirements  without  interruption?  Given  the  complex  and  multifaceted  activities  of  a 
resource  management  system,  this  issue  deserves  careful  consideration. 

1.  Data  Entry 

The  procedure  of  data  entry  should  be  strictly  controlled  to  insure  accuracy 
and  consistency  of  the  data.  In  order  to  accomplish  this,  a  position  responsible  for  data 
entry  can  be  assigned  under  the  director  of  the  resource  management  department.  The 
frequency  of  data  entry  should  be  divided  into  two  categories:  periodic  and  occasional. 
The  resources  expended  in  the  unit's  ordinary  activities  are  recorded  by  the  total 
amount  during  the  period  (weekly  or  monthly).  Expenditures  on  special  events,  such 
as  field  exercise  or  annual  combined  operation,  are  input  at  the  time  of  resource 
activity.  These  two  types  of  data  entry  are  recommended  to  facilitate  future  data 
manipulation  associated  with  a  specific  event. 

2.  Database  Maintenance 

In  the  course  of  data  base  implementation,  some  actions  should  be  taken  to 
insure  the  DBMS  is  serving  the  users  as  intended.  These  include  security  procedures 
and  database  performance  monitoring.  Unauthorized  access  and  modification  of  the 
database  can  cause  serious  problems.  Especially  since  the  DRMS  is  dealing  with 
military  materials,  the  disclosure  of  data  about  key  materials  related  to  combat 
readiness  must  be  protected.    The  division  needs  to  install  security  features  carefully 
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designed   to    minimize   unnecessary    overclassified   materials.     In    addition,    backup 
procedures  are  required  to  protect  against  hardware  failure  or  disk  loss. 

The  data  base  must  be  able  to  provide  the  user  with  a  high  degree  of 
continuous  performance.  This  performance  is  based  on  matching  the  unit's  information 
requirements  with  current  technology.  The  database  administrator  is  expected  to 
maintain  a  systems  performance  balance  among  the  hardware,  software,  and 
applications.  If  users  of  the  division's  DBMS  complain  about  the  process  time,  access 
procedure,  or  the  application  capabilities  of  the  system,  mechanisms  must  be  available 
for  the  possible  resolution  of  the  matter. 

3.  Data  Integrity 

Counteracting  the  advantages  of  the  data  base  environment  is  the  increased 
threat  resulting  from  centralized  data.  Since  many  applications  are  performed  with  the 
same  data,  improper  editing  or  inconsistent  data  handling  among  the  on-line  users 
makes  transaction  auditing  difficult.  Furthermore  since  other  applications  may 
continue  to  access  incorrect  data,  the  problem  can  give  rise  to  a  complicated  situation. 

In  order  to  preserve  the  database  integrity  effectively,  standards,  testing, 
procedures,  and  policies  should  be  enforced  by  responsible  authorities  [Ref.  11:  p.  142] 
Those  procedures  enable  the  DBMS  personnel  to  maintain  integrity,  detect  the 
problems,  and  correct  them  more  easily. 

4.  Advent  of  a  New  Position:  DBA 

The  above  functions  introduced  by  the  database  system  imply  the  necessity  for 
new  authorities  to  take  comprehensive  responsibility  for  the  data  base.  Previously 
individual  data  was  controlled  by  individual  departments,  but  the  integration  of  data 
shared  among  groups  requires  coordination  and  centralized  control  among  the  users. 

Nowadays  the  position  of  data  base  administrator  (DBA)  is  common  in 
organizations  with  database  practices.  A  DBA  can  be  created  as  a  new  staff  officer  in 
the  division.  Considering  the  current  organizational  structure  of  the  Army  division,  the 
DBA  may  be  positioned  as  in  Figure  5.24. 

The  operation  of  the  DRMS  ranges  over  all  the  general/ functional  staffs 
(departments),  however  the  DBA  must  control  and  coordinate  the  activity  of  data 
entry  and  maintenance.  Even  though  each  department  may  have  its  own  data 
administrator  who  is  responsible  for  maintaining  the  department-related  data,  the  DBA 
assumes  the  higher  and  final  responsibility  about  the  administrative  and  technical 
tasks.  A  DBA  can  be  placed  under  the  EDP  manager  supervised  by  the  G-5  (Resource 
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Figure  5.24    DBA  of  the  Army  division. 

Management  Department),  because  the  DBMS  is  a  part  of  EDP  (computer  center) 
group. 

F.       SUMMARY 

The  intent  of  this  chapter  is  to  show  how  a  relational  database  helps  the  DRMS 
meet  its  complicated  and  diverse  information  requirements. 

This  chapter  first  explained  the  DRMS  environmental  issues  for  which  the  DB 
system  is  supposed  to  operate.  Since  the  DBMS  is  a  new  system  compared  to  the 
current  DRMS  file  system,  we  proposed  four  major  factors  be  developed  in  order  to 
exploit  the  advantage  of  the  relational  DB  system: 

•  Detailed  coding  system 

•  Stand  price  system 

•  Measurement  unit 

•  Reporting  document  format 

Following  the  logical  model  of  the  DRMS  system,  a  relational  schema  was 
designed  similar  to  an  input  record  format  in  a  file  system  environment.  Designing  a 
relational  schema  requires  elaborate  efforts  to  eliminate  various  anomalies  and  to 
facilitate  data  manipulation.  We  created  10  relations  to  cover  all  information 
requirements  identified  in  Chapter  III. 
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SQL  operations  were  illustrated  to  show  the  flexible  and  powerful  data 
manipulation  application  capability  of  the  relational  DBMS.  The  three  sample  cases  in 
this  chapter  demonstrate  only  a  part  of  the  full  capability  of  the  system.  Once  the 
relational  DBMS  is  established,  the  user  can  produce  many  kinds  of  information  with 
SQL  query  operations.  The  SQL  data  manipulation  language,  though  relatively  simple 
to  use,  proves  to  be  a  very  flexible  and  powerful  tool. 

Finally,  administrative  aspects  of  the  DBMS  were  briefly  discussed:  data  entry; 
database  maintenance;  data  integrity.  The  introduction  of  DBMS  requires 
corresponding  change  in  the  division's  information  requirements  environment.  A  new 
position  of  DBA  group  was  recommended  to  be  responsible  for  the  technical  and 
administrative  aspects  of  the  data  base. 
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VI.  DATA  ANALYSIS  AND  APPLICATIONS 

The  objective  of  defense  resource  management  system  (DRMS)  is  to  help 
commanding  officers  manage  and  control  the  total  resources  of  their  units  effectively 
and  efficiently,  and  to  enable  them  to  make  resonable  decisions  on  the  basis  of  timely, 
accurate,  and  relevant  information. 

To  accomplish  this  objective,  up  to  this  point,  we  have  reestablished  the 
information  requirements  for  DRMS  and  built  a  suitable  database  management  system 
in  order  to  obtain  meaningful  output  data  easily. 

Some  information  can  be  directly  obtained  from  the  output  data.  However,  to  get 
more  accurate  and  relevant  information  we  must  apply  some  analytical  techniques  or 
models.  Therefore,  -in  this  chapter,  we  introduce  some  analytical  techniques  and  models 
for  decision  making  that  can  be  applicable  to  the  ROK  Army  division  level. 

A.       REGRESSION  MODEL  FOR  EXPENSE  COEFFICIENT 

Regression  analysis  is  powerful  method  of  estimation  and  the  most  commonly 
used  casual  approach  to  forecasting.  It  is  quite  flexible  and  can  include  any  number  of 
factors  in  the  forecasting  models. 

Many  managerial  decisions  require  predictions  or  forecasts  of  future  events. 
These  predictions  frequently  are  based  on  historically  observed  relationships  between 
variables.  These  predictions  could  be  made  by  using  regression  analysis.  This  technique 
is  widely  used  to  determine  the  statistical  relationship  between  two  (or  more)  variables 
and  make  predictions  of  one  variables  on  the  basis  of  the  other(s). 

1.  Simple  Linear  Regression 

In  a  simple  linear  regression  analysis  we  attempt  to  develop  a  linear  model 
from  which  the  values  of  a  dependent  (i.e.,  response)  variable  cab  be  predicted  based 
on  particular  values  of  a  single  independent  variable.  To  develop  the  model  a  sample  of 
N  independent  pairs  of  observations  (Xj  Yj),  (X2  Y2),  ...,  (Xn  Yn)  are  obtained, 
where  Xj  represents  the  ith  value  of  the  independent  or  predictor  variable  X  and  where 
Yj  represents  the  corresponding  response  -  that  is,  the  ith  value  of  the  dependent 
variable  Y. 
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To  study  the  possible  underlying  relationship  between  X  and  Y,  the  n 
individual  pairs  of  observations  can  be  plotted  on  a  two-dimensional  graph  called  a 
scatter  diagram.  The  dependent  variable  Y  is  plotted  on  the  vertical  axis,  while  the 
independent  variable  X  is  plotted  on  the  horizontal  axis.  The  scatter  diagram  aids  the 
researcher  in  selecting  an  appropriate  regression  models.  By  examining  the  plotted 
sample  points,  the  researcher  attempts  to  project  the  underlying  mathematical 
relationship  that  may  exist  between  X  and  Y. 

In  a  simple  regression  model  wherein  there  is  but  one  predictor  variable  X, 
this  functional  relationship  can  be  expressed  as 

Y=  MXi)  +  z{  (cqn6.1) 

where  any  observed  value  Y-  in  the  population  would  be  a  function  of  the  true 
mathematical  model  fl[X-)  plus  some  residual  £•.  The  £•  term  represents  scatter  above 
and  below  the  regression  equation. 

If  the  scatter  diagram  indicates  a  possible  linear  relationship  between  X  and 
Y,  the  population  regression  model  (6.1)  can  be  re-expressed  as 

Yj-  P0  +  PjXi  +  fij  (eqn6.2) 

where  the  two  unknown  parameters  Pq  and  Pj  are  necessary  for  determining  a  straight 
line.  Pq  is  the  true  intercept,  a  constant  factor  in  the  regression  model  representing  the 
expected  or  fitted  value  of  Y  when  X  =  0.  pj  is  the  true  slope;  it  represents  the 
amount  that  Y  changes  (either  positively  or  negatively)  per  unit  change  in  X. 

Since  we  do  not  have  access  to  the  entire  population,  we  cannot  compute  the 
parameters  Pq  and  Pj  and  obtain  the  population  regression  model.  The  objective  then 
becomes  one  of  obtaining  estimates  Dq  (for  Pq)  and  bj  (for  Pj)  from  the  sample. 
Usually  this  is  accomplished  by  employing  the  method  of  least  squares.  With  this 
method  the  statistics  Dq  and  bj  are  computed  from  the  sample  in  such  a  manner  that 
the  best  possible  fit  within  the  constraints  of  the  squares  model  is  achieved.  That  is,  we 
obtain  the  linear  regression  equation 

Yj  =  bQ  +  bjX;  (eqn  6.3) 

such  that  E  (Y-  -  Y-)  =  L  £2i  is  minimized. 
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2.  Multiple  Regression  Model  • 

In  multiple  regression  at  least  two  independent  variables  are  used  to  predict 
the  value  of  a  dependent  variable.   The  general  form  of  multiple  regression  is 

Y  =  a  +  b{X{  +  b2X2  +  ...  +  bkXk 

The  technique  for  estimating  the  parameters  of  the  regression  equation  are  similar  to 
those  used  for  simple  regressions.  A  multiple  regression  model  is  much  more 
complicated  to  use  than  a  simple  regression  model.  Generally  speaking,  the 
assumptions  about  the  statistical  form  of  the  data  and  the  procedures  used  for 
assessing  the  reliability  of  the  estimates  are  extensions  of  those  associated  with  simple 
linear  regression. 

Estimates  of  the  intercept  and  regression  coefficients  are  obtained  from  a  set 
of  normal  equations,  the  same  as  for  simple  regression,  although  the  normal  equations 
become  more  complicated  and  laborious  to  solve  as  the  number  of  independent 
variables  increases.  Fortunately,  computer  package  for  multiple  ression  model  is 
developed  and  we  can  easily  get  regression  equation  from  computer  package. 

3.  Application  of  Regression  Models 

iMaking  a  budget  for  the  petroleum  or  repair  parts  of  a  specific  model  of 
vehicle,  we  usually  confront  some  problems;  how  we  should  determine  the  criteria 
(petroleum  consumption  ratio  per  kilometer,  repair  part  consumption  ratio  per 
kilometer)  for  operating  the  vehicle  by  1  kilometer,  and  how  we  can  determine  the  fixed 
amount  of  their  consumption  which  are  not  related  with  the  operation  of  the  vehicle. 
Furthermore,  we  should  take  into  consideration  the  activity  under  given  conditions: 

•  Logistic  transportation  and  administration  activity  (LOG  &  ADM) 

•  Training  and  military  operation  activity  (TRN  &  OPT) 

•  Commanding  and  staffing  activity  (CMD  &  STF) 

Different  criteria  determined  depending  upon  the  activities  and  road  conditions  are 
more  relevant  and  accurate  than  one  simple  criterion  obtained  by  simple  calculation 
that  is  used  in  the  current  DRMS  system. 

Assuming  that  there  are  5  same  model  jeeps  in  the  organizational  unit,  let's 
consider  two  kinds  of  the  expense  collecting  data  format  for  5  jeeps.  One  format  as 
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shown  in  Table  6  is  now  utilized  in  the  current  DRMS  system.  With  this  format  we 
can  get  0.465  I  /  km  by  dividing  the  total  amount  of  petroleum  (11,480  ltr)  by  total 
operating  distance  (24,700km). 


TABLE  6 
CURRENT  DATA  COLLECTING  FORMAT 


Jeep  No. 

Petroleum 
(ltr) 

Repair  parts 
Expense  ( $ ) 

Operational 
Distance( km) 

1 

2,155 

350,000 

4,500 

2 

2.255 

390,000 

4,700 

3 

1,545 

230,000 

2,800 

4 

3,310 

415,000 

8,100 

5 

2,215 

387,000 

4,600 

Total 

11,480 

1,772,000 

24,700 

On  the  other  hand,  if  we  apply  simple  regression  model  with  the  same  data, 
we  can  easily  obtain  a  regression  equation  as  follows: 

Petroleum  consumption  per  km  =  671  +  0.329  x  Distance(km). 

The  result  obtained  from  simple  regression  model  is  more  accurate  and  relevant  than 
one  obtained  by  the  simple  division  method.  Allocating  the  petroleum  for  10,000  km  of 
operation,  we  must  allocate  the  petroleum  to  the  organizational  unit  by  4,650  ltr.,  if  we 
use  the  criterion  obtained  from  the  simple  division  method.  However,  if  we  use  the 
criterion  obtained  from  simple  regression  model,  we  can  allocate  petroleum  to  the 
organizational  unit  by  the  only  3,9611tr.  (671  +  0.329  x  10,000km).  In  the  simple 
regression  equation,  the  number  671  means  the  fixed  consumption  amount  occured  not 
related  to  the  operating  activity. 
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The  other  data  collecting  format  created  in  the  new  DRMS  as  shown  in  Table 
7  is  well  improved  one  for  multiple  regression  model. 


TABLE  7 
NEW  DATA  COLLECTING  FORMAT 

Jeep 
No. 

Petroleum 
used 
( Itr.  ) 

Operational        Distance   (km) 

LOG  &  ADM 

TRN  &  OPT 

CMD   &   STF 

1 

2,155 

1,000 

500 

3,000 

2 

2,255 

700 

500 

3,500 

3 

1,545 

500 

300 

2,000 

4 

3,310 

2,200 

700 

5,200 

5 

2,215 

1,200 

600 

2,800 

TOT 

11,480 

5,600 

2,600 

16,500 

We  can  compute  the  expense  coefficient  of  each  activity  from  data  retained  in  the  new 
format  by  using  computer-aided  multiple  regression  model.  We  can  easily  obtain  the 
multiple  regression  equation  by  using  computer  package  (MINITAB)  as  follows: 

Y   =    520    +    0.214Xj    +    0.85X2    +    0.331X3 

Y  :  Petroleum  consumption  amount 

Xj  :  Distance  for  logistic  transportation 
and  administration  activity 

X2  :  Distance  for  training  and  military  activity 

X3  :  Distance  for  commanding  and  staffing  activity 
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In  this  multiple  regression  equation,  regression  coefficients  (0.214,  0.85,  and 
0.331)  contain  very  useful  information.  They  represent  the  consumption  coefficients  of 
each  activity.  If  we  get  these  coefficients,  we  can  forecast  the  needs  of  petroleum  for 
certain  level  of  activities  with  more  accuracy  and  relevance. 

For  example,  if  50,000  km  is  for  logistic  and  administration  activity,  20,000  km 
is  for  training  and  military  operation  activity,  30,000  km  for  commanding  and  staffing 
activity,  then  the  total  amount  of  petroleum  needed  in  those  activities  (38,150  Itr.)  can 
be  obtained  from  the  above  multiple  regression  equation  (520  +  0.214x50,000  + 
0.85x20,000  +  0.331x30,000). 

In  conclusion,  simple  regression  model  is  better  than  simple  division  method, 
and  multiple  regression  model  is  the  best  of  the  three  methods  in  providing  the  criteria 
and  equation  that  indicate  influential  elements  for  activities.  Therefore,  the  first  data 
collecting  format  should  be  converted  to  the  second  format  for  the  new  system  with  a 
view  to  obtain  more  accurate  and  meaningful  information. 

B.       INPUT-OUTPUT  ANALYSIS  FOR  TOTAL  COST 

1.  General 

In  this  section,  we  discuss  how  forecasts  can  be  made  using  an  input-output 
model.5  The  procedure  is  presented  both  in  matrix  algebra  and  in  words.  The 
theoretical  discussion  is  integrated  with  a  numerical  example. 

Input-output  analysis  examines  the  interrelations  existing  between 
components  of  a  system.  It  does  this  by  specifically  accounting  for  the  resource  flows 
that  bind  the  various  components  of  the  system  into  an  interdependent  whole.  The  first 
step  in  using  input-output  analysis  is  to  divide  the  components  of  the  system  being 
modeled  into  "sectors".  A  sector  represents  one  organization  or  function.  In  the  models 
of  the  economy,  a  whole  industry  -  such  as  steel  -  becomes  one  sector.  In  our  model  of 
the  ROK  Army  division,  sectors  represent  functions  such  as  Ground  Forces  and  Army 
Aviation  Unit. 

These  sectors  are,  in  turn,  divided  into  two  groups:  those  that  support  other 
sectors  and  those  that  don't.  Sectors  that  support  other  sectors  produce  goods  and 
services  and,  in  turn,  consume  goods  and  services;  such  sectors  are  called  processors  or 


Our  procedure  describes  a  static,  open  model.  A  static  model  forecasts  each  year 
independently  of  other  years  (that  is,  it  does  not  allow  for  the  dynamic  interplay  of  one 
year  on  another).  An  open  model  assumes  that  the  output  of  some  activities  (called 
final  users)  are  not  measured  by  the  model. 
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support  sectors.  Those  that  don't  support  others  but  who  do  consume  the  output  of 
the  processors,  consisting  mainly  of  the  operating  forces,  are  called  final  users:  final  in 
the  sense  that  they  are  the  final  step  in  the  system. 

The  resource  flows  that  bind  the  system  together  are  captured  by  measuring 
each  sector's  output  provided  to  other  support  sectors  and  to  final  users  (operating 
forces).  These  output  measures,  or  workload  indicators,  relate  changes  in  the  final  users 
to  changes  in  the  workloads  and  the  resources  consumed  by  the  support  sector.  It  is 
not  necessary  that  these  output  measures  be  actual  output.  In  the  work  described  later, 
we  utilized  proxy  variables  for  our  output  measures.  Proxy  variables  are  data  which  do 
not  directly  measure  the  workload  of  the  support  activity  but  which  are  assumed  to 
vary  roughly  in  proportion  to  a  direct  measure.  For  example,  the  actual  output  of 
recruit  training  is  trained  recruits.  Our  proxy  variable  is  the  number  of  Army  division 
enlisted  men  in  each  sector.  The  rationale  is  that  on  the  average  the  number  of  trained 
recruits  required  by  each  sector  will  vary  in  proportion  to  the  number  of  men  in  that 
sector. 

This  workload  information  is  then  organized  into  a  matrix  (called  the 
transactions  matrix)  which  has  one  row  for  each  processor  and  as  many  columns  as 
there  are  processors  and  final  users.  Each  row  represents  the  output  of  that  support 
sector  and  shows  how  that  sector's  output  is  allocated  to  each  of  the  consuming 
sectors,  including  itself.  One  sector's  output  becomes  another  sector's  input  so  that 
each  entry  in  a  row  is  an  input  into  the  sector  represented  by  the  column.  Thus,  and 
this  is  the  unique  feature  of  this  matrix,  each  element  in  the  matrix  is  simultaneously 
an  output  of  the  sector  represented  by  the  row  and  an  input  to  the  sector  represented 
by  the  column.  (The  name  input-output  comes  from  this  layout.)  In  addition,  all 
sectors,  both  processors  and  final  users,  need  inputs  not  only  from  other  sectors  within 
the  system,  but  also  inputs  from  outside  the  system,  such  as  labor  and  equipment. 
These  primary  inputs  can  be  measured  in  any  appropriate  unit  and  are  added  to  the 
above  relationships  by  expanding  the  matrix  to  include  more  rows  representing  the 
additional  inputs. 

To  illustrate  the  use  of  input-output  analysis,  we  have  constructed  an  example 
utilizing  sample  data  for  the  ROK  Army  division  level  for  fiscal  year  1987.  Table  8 
shows  the  two  processors  and  two  final  user  sectors,  their  abbreviations  used  in  later 
tables,  the  proxy  variables  for  the  support  sectors,  and  the  primary  inputs  for  this 
example;  Table  9  is  the  Transaction  Matrix.    The  rows  of  the  upper  quadrants  of  the 


92 


Transaction  Matrix  represent  the  flow  of  support  from  support  sectors  to  both  support 
sectors  and  final  users.  The  columns  of  the  lower  left  quadrant  are  the  resources  that 
are  inputted  to  the  support  sectors  for  them  to  generate  their  total  outputs.  In  this 
case,  the  Base  Operating  Support  sector  needs  10  units  of  MP  and  230  units  of  O&M 
to  produce  its  total  output  of  60  units  (  10  +  10  +  20  +  20  =  60  ). 


TABLE  8 

SECTORS  AND  PROXY  VARIABLES  USED  IN  SAMPLE  PROBLEM 

Support  Sectors 

Proxy  Variables 

1.  Base  operating  support 
(BOS) 

Military  pay  (MP), 
Operations   & 
maintenance  (O&M) 

2.  Logistics  (LOG) 

Operations   & 
maintenance  (O&M) 

Final  Users  Sectors 

Primary  Inputs 

1.  Ground  Forces   (  GF  ) 

1.  Military  personnel 
(  MP  ) 

2.  Army  Aviation  UNit  (AAU) 

2.  Operations  & 

maintenance  (O&M) 

The  Transaction  Matrix  can  be  functionally  divided  into  four  quadrants  as 
shown  in  Table  10.  The  rows  of  the  U  and  V  matrices  represent  the  flow  of  support 
from  the  processors  to  both  processors  and  final  users.  The  columns  of  W  and  Z  are 
the  inputs  to  each  sector  from  outside.  Assuming  there  are  m  processors,  n  final  users 
and  k  resource  inputs,  U  is  mXm,  V  is  mXn,  W  is  kXm  and  Z  is  kXn.  In  terms  of  table 
9,  the  U  matrix  is  a  2  x  2  square  matrix,  V  is  a  2  x  2  matrix,  W  is  a  2  x  2  matrix  of 
resource  resource  inputs,  and  Z  is  a  2  x  2  matrix  of  resource  inputs  for  the  final  users. 

This  matrix  of  inputs  and  outputs  in  either  dollars  or  units  of  real  output  is 
just  a  form  of  double  entry  bookkeeping.  The  usefulness  of  input-output  analysis  is 
that  this  matrix  can  be  transformed  into  other  matrices  which  can  be  manipulated  to 
show  structural  interdependence  and  to  predict  the  impact  on  support  of  force  changes. 
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TABLE  9 
TRANSACTION  MATRIX 

Processors 

Final 

User 

BOS 

LOG 

GF 

AAU 

BOS 

10 

10 

20 

20 

LOG 

40 

10 

20 

30 

MP 

10 

10 

20 

20 

O&M 

230 

260 

500 

600 

TABLE 
TRANSACTION  MATRIX  DIVIDE 

m  columns 
m  rows                     U 

10 
•D  INTO  FOUR  QUADRANTS 

n  columns 
V 

k  rows                     W 

Z 
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2.  Transforming  Step 

Several  steps  are  involved  in  transforming  the  subdivided  Transactions  Matrix 
into  a  predicting  device. 

a.  Step  I. 

In  step  1,  each  row  of  U  and  V  is  summed  to  create  a  column  vector,  X,  of 
total  output. 

m  n 

EU,    4-   LVij    =    Xj 

j=l 

i  =  l,...,m 

In  this  example  of  Table  9,  Xj  =  60. 

b.  Step  2. 

Each  row  of  V  is  summed  to  create  a  column  vector,  Y,  representing  that 
part  of  total  output  being  consumed  by  the  final  users. 

n 

£  Vjj   -    Yj  i  =  l,...,m 

1=1 


In  this  example,  Y  is: 


40 
50 


c.  Step  3. 

Each  element  of  the  jth  column  of  U  is  divided  by  the  jth  element  of  X  to 
create  the  mXm  matrix  A. 


uij 


=    Aij  i  =  U:-,m 

Xj  j  =  l,...,m 
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Step  3  converts  the  U  matrix,  which  contains  gross  data  into  a  matrix  of  proportional 
coefficients,  commonly  called  the  A  matrix.  The  A  matrix  is  a  square  matrix  with  as 
many  rows  and  columns  as  there  are  processors.  In  words,  A  is  found  by  first 
summing  across  each  row;  this  sum  gives  the  total  output  of  that  sector.  Then  each 
element  in  the  corresponding  column  of  U  is  divided  by  that  total.  The  result,  for  each 
support  sector,  is  the  number  of  units  of  inputs  required  from  each  of  the  sectors 
including  itself  for  each  unit  of  its  output. 

For  example,  column  1  of  U  from  table  9  is: 

10 
40 

Each  element  is  divided  by  Xj  =  60.  These  results  form  column  1  of  A  which  is: 

10/  60  =  0.1667 

40  /  60  =  0.6667 

Table  1 1  shows  the  A  matrix  for  our  example.  The  entries  in  Table  1 1  are  interpreted 
as  follows:  0.6667  (at  column  1,  row  2)  means  that  for  every  unit  of  BOS  output,  LOG 
must  supply  0.6667  of  a  unit  of  its  output.  Our  model  is  built  upon  these  proportional 
relationships. 


TABLE  11 
THIS  IS  THE  (A)  MATRIX. 


BOS 

LOG 

BOS 

0. 1667 

O. lOOO 

LOG 

0. 6667 

0. 1000 
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d.  Step  4. 

The  matrix  is  subtracted  from  the  identity  matrix  and  then  inverted.6  See 
Table  12  for  the  inverse  in  our  example.  This  inverse  matrix  (I  -  A)  is  our  forecasting 
tool.  The  logic  behind  its  derivation  and  use  can  be  understood  by  considering  the 
following  series  of  equation: 


X    =    AX    +    Y 

X  -  AX    =    Y 

(I  -  A)X    =    Y 

X    =    (I-  A)_1Y 

e.  Step  4. 

As  before,  X  is  a  column  vector  representing  total  output  from  the  support 
establishment  and  Y  is  a  column  vector  representing  that  part  of  total  output  being 
consumed  by  the  final  users.  AX  is  column  vector  representing  output  consumed  by 
processors. 

The  (I  -  A)  matrix  has  a  very  important  property;  each  of  its  elements  r^: 
shows  the  total  support  (as  measured  by  the  proxy  variables)  sector  i  must  provide  to 
enable  sector  j  to  provide  one  unit  of  its  output.7 

The  usefulness  of  the  (I  -  A)  matrix  is  that  once  it  is  developed  for  one 
set  of  demands  it  can  be  multiplied  times  a  new  level  of  demands  by  final  users  (e.g.,  a 
new  force  level),  denoted  by  Y',  to  obtain  an  estimate  of  the  total  output  requirements 
from  each  of  the  support  sectors.  Given  Y',  the  required  output,  X',  is  estimated  by: 

X'    =    (I  -  A)_1Y' 

where 

m 
Y'j  =  EV'jj  i  =  1 m 


The  inverse  of  a  matrix  has  the  same  role  in  matrix  algebra  that  the  reciprocal 
plays  in  regular  numbers.  That  is  if  AX  =  Y,  then  X  =  1/A  or  AY.  The  inverse  of  a 
matrix  is  denoted  by  the  same  symbol  -1. 

7The  inverse  matrix  (I  -  A)"1  =  I  +  A  +  A2  +  A3  +  ...  The  expression  I  +  A 
represents  direct  support.  Each  round  of  support  on  support  is  represented  by  An  The 
inverse  represents  the  sum  from  n  =  0  to  n  =  <x>  of  An 
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TABLE  12 

THIS  IS  THE  (I  -  A)  INVERSE  MATRIX. 

A  = 

0. 1667           0, 1000 
0. 6667           0. 1000 

I    -    A   = 

1      0 
0      1 

- 

0. 1667             0. 1000 
0. 6667              0. 1000 

0. 8333           -    0. 10000 

-    0. 6667                0. 90000 

0. 8333              -    0. 1000 

-] 
(I    -    A    ) 

L 

-   0. 6667                  0. 9000 

(0.  8333)(0.9)    -    (-   0.6667)(- 

0.  1) 

1.3171                0.1463 

0.9756                1.2195 

For  example,  let's  calculate  the  required  total  support  (X')  for  next  year  with  a  doubled 
Ground  Forces  and  5  time  Army  Aviation  Units.  We  can  obtain  the  required  total 
support  of  BOS;  212  and  the  required  total  output  of  LOG;  369  as  shown  in  Table  13. 

The  inverse  matrix,  (I  -  A)"1'  can  also  be  used  to  estimate  the  marginal 
impact  of  a  force  change.  Defining  the  force  change  as  A  Y',  then  the  marginal  impact, 
A  X',  is  computed  by: 

AX'     =     (I-A)_1AY' 

/.  StepS. 

The  resources  required  to  produce  the  new  output,  X',  must  now  be 
calculated.  We  assume  that  all  resource  requirements  vary  proportionately  to  output. 
Our  resource  estimates  are  arrived  at  in  the  following  way: 
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TABLE  13 

CALCULATION  OF  THE  REQUIRED  OUTPUT  (X) 

Y'       = 

20x2      +      20x5 
20x2      +      30x5 

= 

140 
190 

X'       = 

1.3171        0.1463 
0.9756        1.2195 

140 
190 

212 

369 

Each  element  in  the  jth  column  of  W  is  divided  by  the  jth  element  of  X: 


=       B: 


Xj 


i  =  lt...,k 

j  =  l,...,m 


In  our  example,  row  1  of  W  from  Table  9  is: 


BOS         LOG 


MP 


10 


10 


First  element  is  divided  by  Xj  =  60  and  second  element  is  divided  by  X2  =  100.  These 
results  form  row  1  of  B  which  is: 


I  10/  60       10/  100  I    =    I  0.1667    0.1000  | 
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The  new  W  ( =  W)  is  calculated  by  multiplying  each  element  in  the  jth  column  of  B  by 
the  jth  element  of  X': 

Wy     =     ByX'j  i  -  1 k 

j  =  l,...fm 

In  the  example,  W"  is  calculated  as  follows: 

I  212  | 
W  =  |  0.1667  0.1000  1  |  | 

I  369  | 

=  72.3 

72.3  indicates  the  number  of  variable  support  personnel  needed  next  year. 

The  matrix  W  contains  the  resource  estimates  for  each  support  sector  for 
forces  contained  in  Y'.  The  matrix  can  contain  as  much  detail  about  resources  as 
desired.  Each  desired  element  becomes  a  row  in  B. 

The  inverse  matrix  can  also  be  used  to  allocate  support  resources  to  forces 
(final  users).  This  is  done  by  calculating  shadow  prices  (which  can  be  defined  as  the 
cost  of  all  resources  used,  including  those  used  indirectly,  to  produce  each  unit  of 
support  output)  and  multiplying  these  shadow  prices  times  the  units  of  support  output 
used  by  each  final  user. 

C.       OPTIMAL  ALLOCATION  OF  REPAIR  PARTS 

The  operational  availability  of  equipment  is  the  most  important  criterion  of  all 
the  concepts  which  have  developed  until  now  for  measuring  the  material  readiness.  It  is 
an  index  of  system  readiness  in  a  mission  environment  which  combines  reliability, 
maintainability  and  supportability  and  probability  that  an  item  can  perform  its 
intended  function  when  called  upon. 

Operational  availability  of  field  equipment  is  heavily  depended  upon  the 
maintainability.  A  certain  level  of  repair  parts  must  be  secured  and  maintained  to  meet 
local  needs  and  keep  the  desired  level  of  maintainability. 
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In  this  section,  we  want  to  deal  with   a  hypothetical  case  in  order  to  determine 
the  accurate  repair  part  level. 

1.  Background 

The  ROK  Army  division  aircraft  are  supported  by  a  large  inventory  of  spare 
parts  that  are  kept  readily  available  to  replace  components  that  fail  on  the  aircraft. 
Many  of  the  failed  components  are  then  taken  to  local  repair  activities  and  fixed.  The 
level  of  inventory  kept  at  the  local  activity  is  directly  related  to  the  frequency  of  failure 
and  the  length  of  time  it  takes  to  repair  a  failed  component  once  it  does  fail. 

2.  Data 

In  order  to  accurately  assess  local  needs,  maintenance  data  is  retained  for  each 
component  that  is  repaired  locally  as  shown  in  Table  14.  The  data  layout  provides 
character  data,  the  failure  dates,  and  the  repair  dates. 


TABLE  14 
MAINTENANCE  DATA  LAYOUT 

a.  Item  identification  data 

1)  national  stock  number 

2 )  component  name 

3)  application 

4)  unit  price 

b.  Item  failure  date 


1)  description 

2)  failure  date 
c.  Item  repair  date 

1)  description 

2)  repair  date 


For  this  case  analysis,  we  are  concerned  with  only  two  of  the  many  data 
elements  retained:  the  failure  date  and  the  repair  date.  Dates  are  maintained  in  the  data 
file  as  Julian  Dates.  Julian  dates  are  four  digit  numbers  that  represent  the  last  digit  of 
the  year  and  the  numeric  order  of  the  day  within  the  year.  The  following  examples  may 
help  to  make  this  clear: 
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Date  Julian  date 


01  January   1986  6001 

02  January  1986  6002 
31  January  1986  6031 
01  February  1986  6032 
25  October  1986  6298 
31  December  1986  6365 
01  January  1987               7001 

Data    collected   using   Julian   dates  are   much    simpler   to    manipulate   than    using 
day/month/year. 

The  data  set  used  actually  in  this  case  are  listed  in  Table  15  as  Julian  dates. 


TABLE  15 

MAINTENANCE  DATA  USED  IN  THE  CASE 

Failure  Date 

Repair  Date 

Failure  Date 

Repair  Date 

6304 

6310 

6316 

6317 

6323 

6325 

6325 

6328 

6314 

6315 

6302 

6307 

6316 

6322 

6302 

6305 

6307 

6312 

6316 

6317 

6302 

6307 

6321 

6322 

6321 

6325 

6301 

6303 

6321 

6321 

6312 

6313 

6329 

6333 

6303 

6306 

6312 

6318 

6313 

6319 

3.  Methodology 

To  determine  the  accurate  inventory  level,  however,  we  are  not  concerned  with 
the  date  that  a  component  fails,  but  rather  with  the  length  of  time  that  it  is  in  NOt 
Ready  For  Issue  (NRFI)  status  -  the  length  of  time  between  failure  and  repair.  To  get 
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a  reasonable  idea  of  the  typical  repair  time,  it  is  also  necessary  to  accumulate  data  over 
a  lengthy  period  of  time,  then  calculate  the  Average  Repair  Turn  Around  Time  (TAT). 
This  allows  us  to  develop  a  proper  inventory  at  a  reasonable  cost. 
4.  Procedure 

Using   the   APL   programming   language,   we   can   determine   the   accurate 
inventory  level  with  the  following  procedures: 

1.  Finding  FIRST  FAILURE  DATE  (FFD) 

2.  Finding  LAST  FAILURE  DATE  (LFD) 

3.  Calculating  ANALYSIS  PERIOD  (AP). 

•  AP    =    LED  -  FFD  +  1 

4.  Determining  TOTAL  FAILURES  (TF). 

5.  Calculating  AVERAGE  DAILY  FAILURES  (ADF). 

•  ADF    =    TF  /  AP 

6.  Calculating  MINIMUM,  MAXIMUM,  AND  AVERAGE  TURN  AROUND 
TIME  (TAT). 

•  TAT    =    Repair  date  -  Failure  date  +  1 

7.  Calculating  AVERAGE  NUMBER  IN  REPAIR  (RBAR). 

•  RBAR    =    ADF  x  average  TAT 

8.  Computing  POISSON  ALLOWANCE. 

•  Using  RBAR  as  the  parameter  of  a  Poisson  distribution,  print  a  table  that 
shows  N  and  the  CDF  of  the  distribution  P(X  <  =  N).  The  meaning  of 
this  table  is  that  if  N  components  are  stocked  (in  a  system  without  repair 
capacity  constraints),  they  will  provide  protection  from  stockout  at  a  level 
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5.  Solution 

Using  a  simple  APL  function,  we  performed  simple  calculations  on  the  input 
data  and  output  the  results  as  shown  in  Table  16.  All  the  APL  program  used  in  this 
case  and  its  solution  are  described  in  detail  in  Appendix  C. 

In  the  Table  16,  N  indicates  the  number  of  components  which  should  be 
stocked  to  provide  protection  from  stockout  at  the  protection  level.  P(X  <  =  N) 
represents  the  probability  that  at  most  N  components  are  needed.  The  PROTECTION 
LEVEL  stands  for  the  level  at  which  they  will  provide  protection  from  stockout  if  N 
components  are  stocked. 

To  maintain  the  100  %  protection  level,  we  must  secure  at  least  12 
components  in  this  case.  If  we  carry  more  than  12  components,  however,  we  must 
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TABLE  16 

RESULTS  OF  ANALYSIS 

*******  DATA  ANALYSIS  ******* 

FIRST  FAILURE  DATE 

:      6301          iU&IAN  DATES. 

LAST 

FAILURE  DATE 

%      6329 

ANALIStS  PERIOD 

I      29               DAIS 

TOTAL  FAILURE 

:      20               UNITS 

&ZEE&GZ  PM&Z  Z&ILURES. 

S      0.6897      UNITS   /  DAI 

TURN 

AROUND   TIME 

MINIMUM 

:      1                DAI 

MAXIMUM 

l      7                  DAIS 

AVERAGE 

:      4.25          DAIS 

HEM 

MIL!  HUMER  IE  EEEAIE       '>     2.931       units 

*******   RE£UL£S.   OF  ANALYSIS   ******* 

EQISSQU  2ISTRIUTI0N 

TABLE 

N 

P(XZN) 

PROTECTION  L.EVEL 

0 

0.05334 

5.334 

1 

0.2097 

20.97 

2 

0.4388 

43.88 

3 

0.6627 

66.27 

4 

0.8267 

82.67 

5 

0.9229 

92.29 

6 

0.9698 

96.93 

7 

0.9895 

98.95 

8 

0.9967 

99.67 

g 

0.9991 

99.91 

10 

0.9998 

99.98 

11 

0.9999 

99.99 

I 

1 

100 

accrue  additional  component  costs  for  keeping  the  same  protection  level.  Therefore,  we 
should  minimize  the  sum  of  the  component  costs  and  carrying  costs  by  determining  the 
accurate  component  level. 
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This  analysis  can  help  a  resource  manager  to  allocate  the  number  of  repair 
parts  which  should  be  stocked  to  provide  protection  from  stockout  at  a  certain 
protection  level  to  the  organizational  unit. 

D.      SUMMARY 

MIS  developed  in  response  to  the  needs  of  management  for  accurate,  timely,  and 
meaningful  data  for  planning,  analyzing,  and  controlling  the  organization's  activities. 
Within  recent  years  there  has  been  increasing  emphasis  placed  on  helping  managers 
make  decisions  on  the  basis  of  good  information.  As  a  result,  the  decision  support 
model  has  become  an  essential  subsystem  within  the  framework  of  MIS. 

If  a  suitable  database  management  system  (DBMS)  is  available,  then  the  decision 
support  model  can  provide  nonroutine  information  through  an  ad  hoc  query  facility  of 
the  DBMS  and  sophisticated  optimizing  techniques  and  statistical  packages  can  be 
used  to  analyze  available  data  and  provide  feedback  capabilities  to  management. 

The  implementation  of  a  decision  support  model  requires  sophisticated 
mathematical  modeling  techniques  (e.g.,  linear  programming  and  statistical 
forecasting),  simulation  methods,  and  high-powered  computer  support.  Recent 
improvements  in  technology  have  made  possible  the  implementation  of  such  models  in 
the  U.S.  Armed  Forces. 

However,  the  automated  data  processing  (ADP)  technology  in  the  ROK  Army  is 
at  a  primitive  stage.  To  meet  the  increasing  needs  of  information  for  decision  making, 
various  decision  support  models  should  be  developed  in  the  ROK  Army  division  level. 
Those  decision  support  models  help  a  commanding  officer  make  key  decisions  and 
thereby  improve  the  effectiveness  of  the  commanding  officer's  problem-solving  process. 

In  order  to  encourage  the  ROK  Army  division  to  develop  various  decision 
support  models  for  reasonable  decision  making,  we  reestablished  the  information 
requirements  and  built  a  suitable  database  in  the  previous  chapters. 

In  this  chapter,  we  showed  three  data  analysis  techniques  (regression  model,  total 
cost  model,  and  component  allocating  model),  as  examples  for  applications,  using  data 
obtained  from  Chapter  V.  These  data  analysis  models  are  usually  used  for  forecasting. 
Forecasting  is  an  important  aid  in  effective  and  efficient  planning,  programming  and 
budgeting  and  it  is  an  integral  part  of  the  decision-making  activities  of  management.  A 
large  number  of  forecasting  methods  are  available  to  management  today.  The 
widespread  introduction  of  computers  has  made  programs  readily  available  for  all 
quantitative  forecasting  techniques. 
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To  be  a  leader  in  military  management  area,  the  ROK  Army  should  reevaluate  its 
current  situation,  try  to  assimilate  advanced  technologies,  and  convert  to  more  effective 
technology  such  as  a  database  management  system. 
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VII.  CONCLUSION  AND  RECOMMENDATION 

The  ROK  Army  is  striving  to  improve  the  efficiency  and  effectiveness  of  its 
Defense  Resource  Management  System  (DRMS).  In  order  to  achieve  complete  self- 
defense  of  ROK  in  a  manner  superior  to  North  Korea,  the  allocation  and  expenditure 
of  limited  defense  resources  must  be  accomplished  in  a  well-managed  cost-effective 
manner. 

Coupled  with  the  establishment  of  the  Defense  Budget  Revolution  Committee 
(DBRC)  in  1983,  the  ROK  Army  has  taken  a  series  of  steps  to  enhance  the  DRMS. 
The  major  objective  of  this  attempt  was  to  establish  a  rational  cyclic  process  of 
planning,  programming,  budgeting,  execution,  and  evaluation.  This  is  called  called 
PPBEES.  The  DBRC  selected  eight  major  functional  areas  to  be  addressed  as  the 
means  for  implementing  the  newly  introduced  budget  system:  1)  decision  making 
process,  2)  planning  -  programming  process,  3)  project  management  system,  4) 
decentralized  management  system,  5)  analysis  and  evaluation  system,  6)  computer- 
based  MIS  system,  7)  resource  management  staff  function,  8)  reorganization. 

So  far,  the  ROK  Army  has  seen  a  considerable  improvement  since  the  initial 
implementation  of  the  DRMS,  however  it  is  also  recognized  that  there  are  still  trials 
and  errors  due  to  a  lack  of  experience.  In  this  thesis,  we  identified  several  limitations  of 
the  current  DRMS: 

•  Emphasis  on  financial  data  which  ignores  operational  data 

•  Unsuitable  and  insufficient  data  collection  methods 

•  Deficiencies  in  the  analysis  of  information  requirements 

•  Inadequate  development  of  data  analysis  and  decision  support  models 

The  data  base  approach  is  regarded  as  the  most  practical  method,  not  only  to  solve  the 
current  problems,  but  also  as  a  means  to  further  improvement.  Since  the  availability  of 
timely  and  accurate  data  about  the  operations,  finance,  and  resource  allocation  is  the 
key  to  the  management  of  an  organization,  the  need  for  an  effective  DRMS  is 
increasing.  A  database  system,  as  a  mechanized  and  controlled  data  pool,  provides 
many  advantages  that  are  not  available  in  the  traditional  file  system.  These  advantages 
include:  1)  reduced  redundancy,  2)  data  application,  3)  program-to-data  independence, 
4)  unpredictable  query,  5)  data  integrity,  6)  security. 
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The  relational  database  model  is  discussed  in  this  thesis  because  the  model 
provides  very  powerful  and  flexible  functions  that  can  be  easily  applied  in  the  DRMS 
because  of  its  ability  to  manage  complicated  and  multi-faceted  activities.  We  showed  a 
basic  design  of  the  relational  database  in  a  preliminary  form  ,  based  on  the  user's 
information  requirements.  Since  a  thorough  study  of  information  requirements  is 
essential  for  database  design,  we  identified  the  information  requirements  for  generating 
formal  reports  and  various  internal  analysis.  Then,  we  determined  the  input  data 
formats  (relations)  realizing  the  importance  of  data  relationships  to  later  data 
manipulation  capability.  The  designer  of  a  relation  should  keep  in  mind  the  principles 
of  independence,  elimination  of  anomalies,  and  ease  of  use.  Data  values  in  a  relation 
have  relationships  with  other  data  values  in  different  relations  according  to  their 
unique  characteristics.  In  order  to  retrieve  the  data  stored  in  a  database,  a  data 
manipulation  language  such  as  SQL  is  used.  The  user  can  obtain  required  data  in  a 
desired  format  by  the  simple  queries.  We  used  some  mock  data  to  demonstrate  SQL 
data  manipulation. 

The  retrieved  data  from  the  database  can  satisfy  the  user  only  when  they  are 
processed  to  provide  information  in  the  useful  form.  As  an  example,  consider  how  raw 
material  is  processed  to  become  finished  goods  and  then  made  available  to  the 
customer  at  a  commercial  value.  We  now  must  adopt  the  appropriate  model  which  can 
satisfy  the  user's  information  requirements  most  effectively.  In  most  cases,  the  applied 
model  is  to  be  selected  prior  to  deciding  the  kind  of  data  to  be  stored.  In  order  to 
maximize  the  computer-based  database  system,  we  must  develop  models  appropriate  to 
our  particular  circumstances. 

The  expected  contributions  to  the  resource  management  system  from  the 
relational  database  can  be  illustrated  as  follows: 

•  Accumulation  of  various  operational  data  for  future  use 

•  Improved  reliability  and  consistency  of  analytical  procedures 

•  Enforced  standards,  integrity,  and  security 

•  Centralized  control  over  the  DRMS 

•  Reduction  of  the  personal  workload  through  office  automation 

•  Easy  generation  of  accurate  and  timely  data 

•  Improved  cooperation  between  the  functional  staff  departments  through  data 
sharing 

•  Reduced  conflicting  requirements  and  redundancy  of  data 
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We  recommend  the  establishment  of  a  database  system  at  the  division  level. 
Since  each  ROK  Army  division  is  already  equipped  with  the  computer  mainframe  as 
distributed  throughout  all  the  military  services,  this  database  system  will  enhance  the 
overall  military  MIS  system. 

In  addition  to  the  above  recommendation,  we  propose  the  implementation  of  the 
following  actions  in  order  to  establish  the  successful  database  system: 

•  Expand  and  develop  the  existing  coding  system  so  each  item  has  one  code 
number 

•  Establish  a  standard  pricing  system 

•  Redesign  Resource  Transaction  Slip  as  previously  recommended 

•  Develop  the  appropriate  analysis  models 

•  Extend  the  computer  system  to  the  company  level  through  a  PC  terminal 
network 

A  well  developed  data  base  management  system  offers  solutions  for  the 
complicated  requirements  of  the  DRMS.  Considering  the  planned  reorganization  of 
the  resource  management  staff,  the  introduction  of  data  base  can  be  the  turning  point 
toward  the  overall  improvement  of  DRMS  in  the  ROK  Army. 
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APPENDIX  A 
SUBCATEGORIES  OF  EACH  INTERNAL  DOCUMENT 

/.    Unit  supply  Transaction  &  Assets 

1)  SUBCATEGORIES  OF  INFORMATION: 

a  Resource  class:  (  7  classes  of  floating  assets;  cash,  foods,  petroleum  &  oil, 
ammunitions,  repair  parts,  individual  maintenance  materials,  and  group 
maintenance  materials ) 

b      Beginning  stock 

c      Logistic  Support  Command 

beginning  due-in(D/I) 

net  request 

receipt 

ending  D/'I 

return 
Organization  unit 

beginning  D/I 

net  request 

supply 

ending  D/I 

return 
e      Ending  stock 
f      Changes  in  stock 

2)  PURPOSE:  Checking  the  supply  support  amount  and  measuring  the  stock. 


2.  Total  Unit  Resources 
1)       SUBCATEGORIES  OF  INFORMATION: 

a      Unit  Name 

b      Cash 

c      Foods 

d      Petroleum  &  Oil 

e      Ammunitions 

f      Repair  Parts 

g      Individual  Materials 

h      Troop  maintenance  materials 
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i       Total 
2)       PURPOSE:  Allocating  resources 

3.  Chances  in  Inventory  Report 

1)  SUBCATEGORIES  OF  INFORMATION: 

a  Resource  class 

b  Beginning  inventory 

c  Receipt 

d  Return 

e  Availability 

f  Utilization 

g  Ending  inventory 

h  Changes  in  inventory 

i  Request 

j  Cancellation  of  request 

k  Ending  due-out  (D/O) 

2)  PURPOSE:  Calculating  the  supply  transactions  between  organizational  unit 
and  division. 

4.  Unit  Resource  D  f  O  Report 

1)  SUBCATEGORIES  OF  INFORMATION: 
a      Unit  Name 

b  Foods 

c  Petroleum  &  Oil 

d  Ammunitions 

e  Repair  parts 

f  Individual  maintenance  materials 

g  Troop  maintenance  materials 

h  Total 

2)  PURPOSE:  Measuring  the  D/O  of  each  unit  by  each  resource. 

5.  Unit  Resource  Utilization  Report 

1)       SUBCATEGORIES  OF  INFORMATION: 

a      Unit  Name 
b      Cash 
c      Foods 
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d  Petroleum  &  Oil 

e  Ammunitions 

f  Repair  parts 

g  Individual  maintenance  materials 

h  Troop  maintenance  materials 

i  Total 
2)       PURPOSE:  Comparing  the  resource  utilization  of  each  organizational  unit. 

6.  Unit  Activity  Expense  Report 

1)  SUBCATEGORIES  OF  INFORMATION: 

a  Activity 

b  Cash 

c  Foods 

d  Petroleum  &  Oil 

e  Ammunitions 

f  Repair  parts 

g  Individual  maintenance  materials 

h  Troop  maintenance  materials 

i  Total  Percentage  (%) 

j  Budget 

k  Expense  /  Budget  (%) 

2)  PURPOSE:  Evaluating  the  expenses  of  each  activity 

7.  Budget  Allocation  and  Expenditure 

1)       SUBCATEGORIES  OF  INFORMATION: 

a      Activity 
b      1/4  Quarter 

•  budget 

•  expenditure 

•  percentage  (%) 
c      2/4  Quarter 

•  budget 

•  expenditure 

•  percentage  (%) 
d      3/4  Quarter 

•  budget 
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•  expenditure 

•  percentage  (%) 
e      4/4  Quarter 

•  budget 

•  expenditure 

•  percentage  (%) 
f      Total 

•  budget 

•  expenditure 

•  percentage  (%) 

2)       PURPOSE:  Measuring  budget  expenditure  by  each  quarter  and  each  activity. 

8.  Cash  Disbursement  Report 

1)  SUBCATEGORIES  OF  INFORMATION: 

a      Unit  name 
b      Personnel  expenses 
c      Material  expenses 
d      Maintenance  expenses 

2)  PURPOSE:  Calculating  cash  disbursement  by  each  item. 

9.  Cash  Disbursement  by  Activity 

1)  SUBCATEGORIES  OF  INFORMATION: 

a      Item 

b      Basic  maintenance  expense 

c      Commanding  activity  expense 

d      Mission  completion  expense 

e      Fringe  benefit  &  welfare  expense 

f      Capital  investment 

g      Supplementary  mission  expense 

h      Total 

2)  PURPOSE:  Calculating  cash  expenditure  by  activity. 
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10.  Equipment  expense  coefficient  report 

1)  SUBCATEGORIES  OF  INFORMATION: 
a      Equipment 

b     Operation  unit 

c      Amount 

d      Petroleum  &  Oil  expense 

•  fixed  expense 

•  variable  expense 
e      Maintenance  expense 

•  fixed  expense 

•  variable  expense 
f      Total 

•  fixed  expense 

•  variable  expense 

2)  PURPOSE:  Providing  criteria  for  allocating  and  budgeting  resources. 

//.   Equipment  operation  by  activity 

1)  SUBCATEGORIES  OF  INFORMATION: 

a      Equipment 

b      Amount 

c      Operating  performance  by  activity 

•  logistic  activity 

•  commander  &  staff  activity 

•  mission  activity 

•  welfare  activity 

•  total 

d      Maintenance  expense 

•  operating  expense 

•  troop  maintenance  expense 

•  field  maintenance  expense 

•  total 

2)  PURPOSE:  Evaluating  the  operating  performance  and  maintenance  expenses 
of  each  equipment. 
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12.  Operating  Performance  of  Each  equipment 

1)  SUBCATEGORIES  OF  INFORMATION: 

a      Equipment  code 

b      Cumulative  operating  performance 

c      Operating  performance  by  activity 

•  logistic  transportation 

•  commanding  &  staffing 

•  mission  completion 

•  welfare 

•  total 

d     maintenance  expense 

•  petroleum  &  oil 

•  troop  maintenance 

•  field  maintenance 

•  substitution  of  repair  parts 

•  total 

2)  PURPOSE:  Evaluating  the  operating  performance  and  maintenance  costs 

of  each  equipment. 

13.  Unit  Training  Cost  Report 

1)       SUBCATEGORIES  OF  INFORMATION: 

a      Type  of  training 

b      Length 

c      #  of  personnel 

d      Distance  of  mobilization 

e      Equipment 

a    vehicle 

b   amounted  vehicle 

c    gunnery 

d   total 
f      Resource  utilization  amount 

•  petroleum  &  oil 

•  ammunitions 

•  repair  parts 

•  cash 
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•  other 

•  total 

2)       PURPOSE:  Comparing  the  resource  utilization  of  organizational  unit 
in  training. 

14.  facility  Maintenance  Cost  Report 

1)  SUBCATEGORIES  OF  INFORMATION: 

a      Type  of  facility 
b      Amount 
c      Size  (square  meter) 
d      Maintenance  costs 

•  cash  budget 

•  material  budget 

•  total 

e      Average  maintenance  cost 

•  per  amount 

•  per  area(size) 

2)  PURPOSE:  Analyzing  the  maintenance  costs  of  each  facility. 

75.   Combat  Equipment  Average  Life  Analysis 
1)       SUBCATEGORIES  OF  INFORMATION: 

a      Combat  urgent  equipment 

b      Amount 

c      Combat  urgent  equipment  and  parts 

•  stock  number 

•  name 

•  unit 

•  unit  price 

d      Total  substitution  times 

•  times 

•  cost 

e      Average  substitutation  times 

•  times 

•  cost 

f      Average  life  (hours) 
g      Average  life  (operation) 
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2)       PURPOSE:  Forecasting  the  demands  of  combat  urgent  equipments  and  repair 
parts. 


16.  Supply  Support  Required  Time  Analysis 

1)  SUBCATEGORIES  OF  INFORMATION: 

a      Resource  class 
b      #  of  transactions 
c      Required  Time  (day) 

0  -  8  days 

8-15  days 

15-30  days 

30  -  60  days 

60  -  90  days 

90  -  150  days 

over  150  days 

2)  PURPOSE:  Analyzing  the  OST  of  supply  support  command. 


17.  Inventory  Stockout  Report 

1)  SUBCATEGORIES  OF  INFORMATION: 

a      Resource  class 
b      30  days 

•  item 

•  money  amount 
c      90  days 

•  item 

•  money  amount 
d      180  days 

•  item 

•  money  amount 
e      Over  1 80  days 

•  item 

•  money  amount 
f      Total 

•  item 

•  money  amount 

2)  PURPOSE:  measuring  the  stockout  of  each  resource. 
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18.  Combat  Urgent  Equipment  and  Repair  Parts  Stockout  Report 

1)  SUBCATEGORIES  OF  INFORMATION: 

a  Type  of  materials 

b  Stock  number 

c  Item  name 

d  Unit 

e  Unit  price  Necessity  amount  needed  in  combat 

f  Amount  of  current  stock 

g  Anticipated  receipt  amount 

h  Degree  of  urgency 

i  Days  of  stockout 

2)  PURPOSE:  Measuring  the  stockout  of  combat  urgent  equipments 

and  repair  parts. 
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APPENDIX  B 
CODING  SYSTEM 

1.       UNIT  CODE 

A.  Formation:  4  digit  number 

B.  Description:  Each  unit  or  functional  staff  office  has  its  own  code  and  is 
responsible  for  the  resource  transaction/expenditure.  The  code  is  assigned  from  the 
higher  level  of  command  through  the  company  level  around  the  division  and  identifies 
the  chain  of  command  of  a  unit. 

C.  Structure 

(1)  1st  digit:  units  classified  into  their  basic  mission. 

-  0:  higher  echelon  of  command  or  adjacent  unit 

-  1:  the  division  headquarter  &  headquarters 

-  2:  functional  staff  office 

-  3:  infantry  unit 

-  4:  artillery  unit 

-  5:  combat  support  unit 

-  6:  service  support  unit 

(2)  2nd  digit:  a  serial  number  of  the  command  or  organizational  unit  under  the 
same  mission 

-  01:  army  command 

-  02:  corps 

-  03:  logistics  support  command 

-  04:  adjacent  unit  (division  level) 

-  21:  personnel  staff  office 

-  22:  intelligence 

-  23:  operations  and  training 

-  24:  logistics 

-  25:  planning 

-  26:  civilian 

(3)  3rd  digit:  the  first  subordiate  unit  of  the  organizational  unit  (battalion  level) 

(4)  4th  digit:  the  second  subordiate  unit  of  the  organizational  unit  (company  leval) 
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EX)  0300:  logistics  support  command 
3100:  1st  infantry  regiment 
3110:  1st  infantry  regiment  1st  battlion 

2.  TIME  CODE 

A.  Formation:   6  digit  number 

B.  Description:  the  date  or  time  period  of  resource  activity 

C.  Structure 

-  1st  2  digit:  year 

-  2nd  2  digit:  month 

-  3rd  2  digit:  day 

EX)  871011:  Oct  11,  1987 

3.  RESOURCE  CODE 

A.  Formation:  4  digit  number 

B.  Description:    All  the  resources  (except  cash)  following  through  the  division  are 
classified  into  their  own  codes  one  by  one,  according  to  their  charcteristics. 

C.  Structure 

(1)  1st  digit:  function  class 

-  1:  firing  E.  -  2:  special  weapon 

-  3:  maneuvering  E.  -  4:  airplane 

-  5:  ammunitions  -  6:  general  equipment 

-  7:  material  I  -  8:  medical  E. 

-  9:  material  II  -  0:  ship 

(2)  2nd  digit  :  resource  class 

-  1:  cash 

-  2:  food 

-  3:  petroleum  &  oil 

-  4:  repair  part 

-  5:  ammunitions 

-  6:  individual  maintenance  material 

-  7:  troop  maintenance  material 

(3)  3,4th  digit:  subclassification  of  each  resource  group(class) 
EX)  7301:  gasoline 
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4.  EQUIPMENT 

A.  Formation:   8  digit  number 

B.  Description:  The  code  ranges  the  whole  equipments  of  the  division  and  the 
individual  equipment  has  its  own  inherent  code  number.  Equipments  are  differentiated 
from  the  other  materials  bacause  they  are  not  consumable  and  operated  semi- 
permanently. 

C.  Structure 

-  1st  digit:  function  class 

-  2nd  digit:  sub-functional  classification 

-  3rd,  4th  digit:  applicable  equipment 

-  5,  6th  digit:  model  number  (last  2  digit  of  the  whole  number) 

-  7,  8th  digit:  equipment  serial  number  of  the  unit 

EX)  1-3-01-05-01:  firing  equipment,  gunnery,  105mm  howitzer,  model  5,  #2 
3-1-01-20-01:  maneuvering,  general  vehicle,  1/4  ton,  model  20,  #1 
3-2-02-02-03:  maneuvering,  combat  vehicle,  M46  Tank,  model  2,  #3 

5.  FACILITY  CODE 

A.  Formation:   3  digit  number 

B.  Description:  Facility  code  includes  real  property  (land,  building  etc.)  and  the  other 
fixed  structures  in  the  unit. 

C.  Structure 

(1)  1st  digit:  facility  class  (according  to  the  purpose) 

-  1:  basic  maintenance  -  2:  training  and  educational 

-  3:  tactical  -  4:  engineering  works 

-  5:  welfare  -  6:  service  support 

-  7:  storage  (warehouse,  tank) 

(2)  2,  3rd  digit:  subclassification  of  the  facility 

6.  PURPOSE  CODE 

A.  Formation:   2  digit  number 

B.  Description:  The  code  indicates  the  purpose  for  which  resources  are  expended, 
c.   Structure 
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(1)  1st  digit  number 

-  1:  basic  mission  activity  (administration  &  supply) 

-  2:  command  and  staff  activity 

-  3:  major  mission  performance  (training,  operations  etc.) 

-  4:  welfare  (medical  ....) 

-  5:  investment  (acquisition  of  equipment,  facility  and  weight  material) 

-  6:  others 

(2)  2nd  digit:  subclassification  of  each  mission  activity 
EX)  31:  training;  20:  commanding  &  staff  activity 

7.  BUDGET  CODE 

A.  Formation:    10  digit  number 

B.  Description:    Classification  for  the  accounting  purpose;  The  current  system  of 
'ROK  defense  budget  item  code  system'  has  alreay  been  developed. 

C.  Structure 

-  1st  2  digit:  budget  chapter(budget  class  group) 

-  2nd  2  digit:  budget  section  (sub-class) 

-  3rd  2  digit:  budget  item  (subsub-class) 

-  4th  2  digit:  budget  sub-item 

-  5th  2  digit:  the  lowest  budget  item 

8.  TRANSACTION  CODE 

A.  Formation:   5  digit  number 

B.  Description:    The  flow  of  resources  in  and  out  of  the  division;  Transactions  are 
identified  based  on  the  four  factors:  item,  flow  line,  objective,  and  frequency. 

C.  Structure 

(1)  1st  digit  number:  Types  of  transaction 

-  1:  supply 

-  2:  return 

(2)  2nd  digit:  resource  class  (1  throug  7) 

(3)  3rd  digit:  transaction  line 

-  1:  army  command  — >  division 

-  2:  corps  — >  division 
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-  3:  logistics  support  command  —  >  division 

-  4:  division  - —  >  subordinate  organizational  unit 

-  5:  organizational  unit  —  >  division 

-  6:  division  —  >  logistics  support  command 

(4)  4,  5th  digit:  the  serial  number  of  transaction  over  the  same  item 

9.       REQUEST  CODE 

A.  Formation:  6  digit  number 

B.  Description:    Every  occurance  of  request/cancel  for  supplies  is  assigned  the  time- 
sequential  number. 

C.  Structure 

(1)  1st  digit:  Request  type  identification 

-  1:  request 

-  0:  request  cancellation 

(2)  2,  3,  4th  digit:  Resource  class  (1  through  7)  and  sub-class 

(3)  5,  6th  digit:   Request  serial  number  annually  given  to  each  resource  class 
(regardless  of  request  or  cancellation) 

EX)   130105:  the  5th  request  for  petroleum  (gasoline);  030105:  cancellation  of  5th 
request 
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-12-  ft  -  ID 

[13]  ft  o  DATES 

[14]  o  o  FFD 

CI 5]  a  o  LfT 

[16]  bo  AP 

[17]  a  o  ADF 

[18]  ft  o  TAT 

[19]  a  o  £BA£ 


APPENDIX  C 

APL  PROGRAM  FOR  THE  OPTIMAL  ALLOCATION  OF  REPAIR 

PARTS 

vcoMPimv 

7  ID  COUP  DATES; FAIL; REPAIR 
ill      ft   oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 
[2]   ft   o  o 

[3]   ft   o  © 

[4]   ft   O  O 

[5]   »   o  © 

[6]   ft   o  PURPOSE    :  WRITING  A   SIMPLE  API.  FUNCTION  TEAT  USES  INPUT  FROM  o 

[7]   ft   o  DIFFERENT  DATA   VECTORS ,  PERFORMS  SOME  SIMPLE  CALCU-        o 

-8-   ft   -  LATIONS  ON  TEE  INPUT  DATA , AND  OUTPUTS  TEE  RESULTS 

-9-   ft   -  IN  A  READABLE  MANNER. 

-10-  ft   - 

-11-    ft      -      KEI   VARIABLE 

ITEM  IDENTIFICATION  DATA 

FAILURE  AND  REPAIR  DATE  OF  COMPONENTS  o 

FIRST  FAILURE  DATE  OF  COMPONENTS  o 

LAST  FAILURE  DATE  OF  COMPONENTS  o 

ANALYSIS  PERIOD  © 

AVERAGE  DAI LI  FAILURE  © 

TURN  AROUND  TIME  © 

AVERAGE  NUMBER  IN  REPAIR  o 

[20]  ft   o  o 

[21]  ft   oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 

[22]  N+(pDATESU2 

[23]  FAIL+N+DATES 

[24]  REPAIR+N  4-  DATES 

[25]  ITEM  ID 

[26]  FAIL   COMPUTE  REPAIR 
7 

7 COMPUTE ID]  7 

7  FAIL   COMPUTE  REPAIR ; FFD ;LFD;AP;TF;ADF; TAT ;MINTAT;MAXTAT;AVETAT;RBAR 

[I]  f  ' 

[2]  ft  CALCULATE  TEE  STATISTICS  OF  INPUT  DATA 

[3]    '  ' 

[4]  FFD+L/FAIL 

[5]  LFD+UFAIL 

[6]  AP+UFD-FFD)+1 

[7]  TF+pFAIL 

[8]  AZ?F-«-rF*AP 

[9]  »     ' 

[10]  ft  COMPUTE  TURN  AROUND  TIME    ,  MINIMUM,    MAXIMUM,   AND  AVERAGE  OF  TAT 

[II]  '  « 

[12]  TAT+ (REPAIR -FAID+1 

[13]    MTtfrar+L/rjir 

[14]  MAXTAT+r/TAT 

[is]  47Er;ir«-(+/riir)*rF 

[16]   •  » 
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fl  COMPUTE  MEAN  DA.ZLI  ESMSM  IU  SSS&ZS 
t  t 

RBAR+ADFxA VET AT 


*******  DATA  ANALYSIS   ******** 


FIRST  FAILURE  DATE 

LAST  FAILURE  DATE 

ANALYSIS  PERIOD 
t 

TOTAL  FAILURE 

AJERAGE  MIL!  ZAILQEZ2. 
» 

TURN  ARQUEU   riSff1 
""7"~ 

MINIMUM 

MAXIMUM 

AVERAGE 
i 


'  ,(.*FFD),  • 

•.(•JOT) 

•,<»ilF),« 


DAIS' 
UNITS '' 


'  ,  (*ADF)  ,  »   OTUTS  /  MI' 


1  A*MAXTAT),' 
1  .(•AF^rAD,1 


CA7' 
DAIS1 
DAIS' 


•  ,  (•JJBJU?), 


££M  MILI  UUMEE  IE  SiEAIE 

« 

t 
i 

*******  RESULTS,  QF  ANALYSIS,   *******' 


UNITS ' 


i 


EQISSQE  QISTRIUTION  TABLE' 


N  PWZN)        PROTECTION  LEVEL' 

■§C+(3,pK)pK,CDF,lQ0xCDF++\(*-RBARlxTRBAR*K)*lK+0,\r*xRBAR 
t 

*  N   =  THE  NUMBER  OF  COMPONENTS  WHICH  SHOULD   BE  STOCKED  TO  PROVIDE' 

PROTECTION  FROM  STOCKOUT  AT  THE  PROTECTOION  LEVEL . ' 
t 

*  P(XZN)    =  PROBABILITY  THAT  AT  MOST  N  COMPONENTS  ARE  NEEDED.' 
i 

*  PROTECTION  LEVEL   =  THE  LEVEL  AT  WHICH  THEY  WILL  PROVIDE    ' 

PROTECTION  FROM  STOCKOUT  IF  N  COMPONENTS  ARE  STOCKED , » 


VITEMLU1V 

V  ITEM  ID iNSN \NAME lAPPLI ; PRICE 
t  i 


i  t 

i **************** 
t  i 

'NATIONAL   STOCK  NUMBER 
'COMPONENT  NAME 
'APPLICATION 
'PRICE  OF  COMPONENT 
V 


ITEM  IDENZlllQATION 


*****************  ' 


' ,9NSN+17+ID 

'  ,9NAME+2*  +  lQ+ID 

' ,9APPLI+8+*2+ID 

'  t(*PRICE+7+ 50 +ID),' 


DOLLARS ' 
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V  DESCRIBE 
[13    'TEIS  WORKSPACE  CONTAINS  THREE  FUNCTIONS    (  2  GENERIC  FUNCTIONS    )  AND* 
[23    'TWO   VARIABLES    tWEICB  CAN  COMPUTE  TEE  STATISTICS  OF  DATA,1 
[33    '  « 

[43    'FUNCTIONS  ARE' 

[53    '  C0MP  *  TJPff  COMPBOW  TO  SEE  BOW  TO  RUN.         » 

[6]    '  ITEM  +  GENERIC  FUNCTION  TO  PRINT  ITEM  IDENTIFICATION. ' 

[7]    '  COMPUTE   «•  CALCULATE  TEE  STATISTICS  OF  DATA.' 

[83    •  ' 

[93    'AND  IT  BAS  DATA   OF  ITEM  ID.    , FAILURE  AND  REPAIR  DATES  OF  TOW' 
[103  'COMPONENTS.' 

7 

VC0MPB0WZU17 

7  COMPBOW 
[13    'TEE  COMPBOW  IS  DYADIC  FUNCTION  TEAT  REQUIRES  TWO  INPUT  MATRICES  TEEN' 
[23    'COMPUTE  TEE  STATISTICS  OF  TEEM  AND  PROVIDE  A  TABLE  TEAT  SBOWS  TEE  NU' 
[33    'MBER  OF  COMPONENTS  AND   CDF  OF  TEE  POISSON  DISTRIBUTION  P(XZ).' 
[«+3    '  » 

[5]    'TEE  SYNTAX  FOR   CALLING  TEE  FUNCTION  IS    :' 
[63    •  ID   COMP  DATES' 

[73    'WBERE  ID  IS  A  ITEM  IDENTIFICATION' 

[83    •      DATES  IS  A  ITEM  FAILURE  DATE  AND  ITEM  REPAIR  DATE  WEICE  JOINED' 
[93    '      WITE    ' , ' . ' 
[103 
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